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
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-exe.
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
environment?
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
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
