Is this a bug or a behavior?
Fri Feb 15 05:29:00 GMT 2013
On 02/13/2013 11:55 AM, Adam Dinwoodie wrote:
> Yes. If you ask for a file, the file doesn't exist, but the file with
> a .exe extension exists, Cygwin will refer you to the .exe version of
> the file. See
Thanks, already aware of that, and it's why I raised this question.
> From that point of view it is; Cygwin is self-consistent, but the very
> nature of attempting to write a Linux-like interface on a
> fundamentally non-Linux like OS means such issues can't be avoided.
I'm not clear on what your standard for "self-consistent" is, or why
filenames are an interface issue.
Those aside, consider these two lines:
$ rm -rf * && mkdir a && touch grep && cp grep /bin/grep a
$ rm -rf * && mkdir a && touch grep && cp /bin/grep grep a
The first line executes as expected while the second, which reverses the
order of files, fails after copying the .exe with the following:
cp: cannot create regular file `a/grep': File exists
Now, take these two sets:
$ rm -rf * && touch foo grep && cp /bin/grep.exe .
$ mv foo grep && ls -i
$ rm -rf * && touch foo && cp /bin/grep.exe .
$ mv -n foo grep
The first set works as expected while the second deletes grep.exe during
the rename even though no-clobber is explicitly passed to mv.
> Nobody has yet suggested a more consistent alternative that still
> allows, for example, a Linux shell script that calls unadorned "grep"
> to work on Cygwin.
How can it ever be consistent while 'filename' and filename.exe' are
allowed to exist in the same directory?
Is there some way to differentiate between a Windows .exe and a Cygwin
binary, like grep.exe, that's intended to execute within the Cygwin
> For your (I really hope) contrived example...
Unfortunately, it wasn't contrived. It was an actual question in a BASH
scripting module that I unnecessarily have to slog through.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin