This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: ln and mkshortcut inconsistent in handling of .exe extension
- From: Christopher Faylor <cgf-rcm at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 1 Oct 2003 13:22:41 -0400
- Subject: Re: ln and mkshortcut inconsistent in handling of .exe extension
- References: <5.1.0.14.0.20030929161708.028d6fe0@127.0.0.1> <5.1.0.14.0.20030929161708.028d6fe0@127.0.0.1> <5.1.0.14.0.20030930123307.0283c890@127.0.0.1> <m2n0cmq8or.fsf@beth.swift.xxx>
- Reply-to: cygwin at cygwin dot com
On Tue, Sep 30, 2003 at 05:15:48PM -0400, Matt Swift wrote:
>That's only part of the stated goals of 'ln'. When CYGWIN contains
>"winsymlinks" (or more accurately, does not contain "nowinsymlinks"
>since "winsymlinks" is the stated default), symbolic links are supposed
>to function both as Cygwin symbolic link and as Windows Shortcuts.
>This is true most of the time, but it is NOT true when the symlink
>target's name given to ln is the name of an executable without its .exe
>extension. In this case, the file created by ln functions as a Cygwin
>symbolic link as expected but contrary to expectation does *not*
>function as a Windows Shortcut. The file created by 'ln', considered
>as a Windows Shortcut, is broken. My points are
cd /bin
ln -s pwd foo
./foo # works
cat ./foo # fails
Why does running foo work? Because Windows CreateProcess call does not
need a .exe extension to run a program. Why does cat fail? Because
'foo' resolves to 'pwd' and, as far as the Windows CreateFile is
concerned, there is no file called 'pwd'.
So, what you are seeing is a side effect of the way windows operates. We're
not going to change ln to automatically add a .exe extension.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/