This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: unzip, find broken by auto handling of .exe file extension
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@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.atzeri@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