This is the mail archive of the
mailing list for the Cygwin project.
Re: ln and mkshortcut inconsistent in handling of .exe extension
At 06:02 PM 9/29/2003, Matt Swift you wrote:
>>> "L" == Larry wrote:
> L> 'ln' and 'mkshortcut' have different behavior for a reason. See
> L> <http://cygwin.com/cygwin-ug-net/using-effectively.html#AEN1516>.
> L> The difference is why 'mkshortcut' exists. Otherwise, we'd just have
> L> 'ln' (which is all we had for quite some time until the need for
> L> different behavior was realized).
>I had seen that discussion. I found no discussion of the particular
>interaction of shortcuts/symlinks and the special handling of the .exe
>extension. To predict the results of the commands I listed, I had to
>Second, I still don't understand why `ln' shouldn't behave the way I
>suggested: how is it better the way it is than if `ln -s' never
>created broken shortcuts
The documentation I directed you to explains why 'ln -s' functions as it
does and from that follows the need for 'mkshortcut'. 'ln -s' doesn't
create 'broken shortcuts'. It creates symbolic links with UNIX semantics.
That's the goal. If you want/need a Windows-style shortcut with all the
semantics that implies, use 'mkshortuct'. Is that the point you were
>and 'ln' (hardlink) defaulted to a target of
>"foo.exe" when the supplied target "foo" doesn't exist?
I'm inclined to agree on this. I think symmetry here would be a good thing.
Still, I haven't done any real investigation of this issue so I was
withholding any bold proclamation on it. I'm sure it fits into the
category of <http://cygwin.com/acronyms/#PTC> if you're inclined to
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html