From: "Andy Hall" <fixpertise-consulting@comcast.net>
To: "'Stephen Anderson'" <stephen.rhoderson@gmail.com>, <cygwin@cygwin.com>
Subject: RE: unzip, find broken by auto handling of .exe file extension
Date: Tue, 13 Sep 2016 01:35:00 -0000 [thread overview]
Message-ID: <002a01d20d53$c74bb580$55e32080$@comcast.net> (raw)
In-Reply-To: <F4E41EBA-31C7-42F7-BDDB-2DFE840B092B@gmail.com>
> 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
next prev parent reply other threads:[~2016-09-13 0:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:00 Stephen Anderson
2016-09-02 18:40 ` cyg Simple
2016-09-02 20:20 ` Stephen Anderson
2016-09-09 13:18 ` Stephen Anderson
2016-09-09 13:59 ` Nellis, Kenneth
2016-09-12 20:37 ` Stephen Anderson
2016-09-12 23:30 ` Marco Atzeri
2016-09-12 23:41 ` Stephen Anderson
2016-09-13 1:35 ` Andy Hall [this message]
2016-09-13 8:00 ` Marco Atzeri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002a01d20d53$c74bb580$55e32080$@comcast.net' \
--to=fixpertise-consulting@comcast.net \
--cc=cygwin@cygwin.com \
--cc=stephen.rhoderson@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).