> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of > Stephen Anderson > Sent: Monday, September 12, 2016 4:31 PM > To: cygwin@cygwin.com > Subject: Re: unzip, find broken by auto handling of .exe file extension > > > > On Sep 12, 2016, at 4:53 PM, Marco Atzeri <marco.atz...@gmail.com> wrote: > > > > On 12/09/2016 21:12, Stephen Anderson wrote: > >> Thanks Ken, good observation. > >> > >> -----Original Message----- > >>> From: Nellis, Kenneth > >>> From: Stephen Anderson > > >>> > See also: > >>> > > >>> > http://stackoverflow.com/questions/32467871/unzip-gives-checkdir-error- > >>> > directory-exists-but-is-not-a-directory#32468314 > >>> > > >>> > The fact that 7z handles this and unzip does not indicates that the > >>> > problem is fixable.. > >> > >>> FWIW, it seems that the same issue is present with tar: > >>> <Ken demonstrates broken tar handling> > >> > >> This means that you can't reliably extract from a tar or zip archive in > >> cygwin. > >> The windoze equivalents do not have this problem. > >> It looks to me like the approach of equating filenames 'foo' and > >> 'foo.exe' is dangerous at the stat(2) level - apparently windoze > >> accomplishes the same trick in a much less destructive way. > >> > >> sja > >> > > > > 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. > > 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. > > sja
Yes, one should expect that the inverse of any file archiving operation would return the original directory structure, possibly with some alterations to permissions and ownership. I have been burned several times by the .exe handling in tar when moving archives back and forth between Linux and Windows. I would agree that this behavior violates the "principle of least astonishment" especially for long-time Unix users. In the past, I have advocated the same solution you proposed. But how does this make commands like "which" and "whereis" which take program names as arguments work properly? adh > -- > 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 -- 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
