This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unzip, find broken by auto handling of .exe file extension


On 13/09/2016 01:30, Stephen Anderson wrote:



This characteristics is needed as windows for historical reason
requested  ".exe" extension for all executable files, while
Unix have not such restriction.

So "cat.exe" is recognized by cygwin also as "cat".
Without this feature all scripts taken by traditional Unix's will
be broken and cygwin will be unusable.

Try this experiment on Linux:

touch foo
mkdir foo

does it work ?

This is not relevant, there is no foo, there is only foo.exe.

foo.exe is also foo for cygwin .
It seems you have problem to understand it


In the case of windows _command_ processing, certain extensions are searched for automatically without creating an equivalency in file names. This means that for the same directory and filename hierarchy, windows and linux archive processing work, cygwin uniquely fails. Not a desirable outcome.

IMHO the only time cygwin should be looking for .exe (or .cmd, .bat etc if desired), is when no match is found on loading a _command_, possibly only from a shell.

Feel free to provide a patch to solve it, but I suspect your solution will be worst then current implementation. There is no way to predict if the search for a file will be used to run it afterwards, so breaking functional scripts or programs.

sja

Regards
Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]