public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
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

  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).