On 09/02/2010 11:45 AM, Daniel Barclay wrote:
I don't quite understand this behavior:
$ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe
C:\tools\emacs-23.2\bin\runemacs.exe
$ C:\\tools\\emacs-23.2\\bin\\runemacs.exe
bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found
In particular, why is it that bash does not understand that Windows
pathname when it is used as a command argument, even though bash and
Cygwin clearly understand it when it is used as a command argument?
Is that behavior a bug (e.g., does bash try to judge whether the command
is an absolute vs. relative pathname without either first converting to
a Unix-style pathname or otherwise recognizing Windows-style pathname)?
You're not the first to notice this, but it's also not the highest
priority on my list to look into, because we already recommend using
POSIX style paths in the first place.
Or is it some known irregularity (resulting from trying to handle both
Windows- and Unix-style pathnames) that couldn't be resolved?
Oh, I'm sure that bash could be patched to be smarter about DOS-style
pathnames. But no one has been bothered by it enough to write a patch yet.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
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
