Re: ln and mkshortcut inconsistent in handling of .exe extension

[Larry Hall <cygwin-lh at cygwin dot com>]

At 05:15 PM 9/30/2003, Matt Swift you wrote:

>>> "L" == Larry wrote:
>
>    L> If you want/need a Windows-style shortcut with all the
>    L> semantics that implies, use 'mkshortuct'.  Is that the point
>    L> you were missing?
>
>I am not asking for "all the semantics", just the ones that are
>documented (user guide 3.5) to exist for all Cygwin symlinks.
>
>I really don't think you understood my first report, and haven't
>realized it yet.  I will make my point again in laborious detail.
>
>
>    >> 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
>
>    L> The documentation I directed you to explains why 'ln -s'
>    L> functions as it does and from that follows the need for
>    L> 'mkshortcut'.  'ln -s' doesn't create 'broken shortcuts'.  It
>    L> creates symbolic links with UNIX semantics.  That's the goal.
>
>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


See, it's good to provide laborious detail.  While what you stated in your 
original message does say this all more succinctly, it does not clearly state
the one difference between 'ln -s' and 'mkshortcut' that you saw as a 
problem.  That in combination with your examples to show the problem with 
hard links helped to obscure your point about 'ln -s' when they are created
as 'winsymlinks' (the default).

I agree with your statement now about Cygwin symlinks in this context.
The "Target" field is empty in the property page under Explorer, so Windows
will certainly not find the link.  You're suggesting there should be symmetry
between how a symlink is made to a file with the '.exe' extension and to the
same file without the '.exe' extension specified.  That's one option.  The 
other is to do as is done in the hard link case and generate an error.  The
former supports portability of existing scripts in most cases, so it is 
likely the best alternative (at the expense of linking to like named files in 
the same directory - a Windows anomaly).


<snip>



>    >> and 'ln' (hardlink) defaulted to a target of
>    >> "foo.exe" when the supplied target "foo" doesn't exist?  
>
>    L> I'm inclined to agree on this.  I think symmetry here would be a good thing.
>
>If you agree about that, I am very sure you will agree with my other
>point, once you undertsand it, because it does not even involve the
>small change to Cygwin semantics that the second point does (the
>second point involves a change to Cygwin semantics because you would
>get no error and a hardlink in certain cases where before you got an
>error; my first point suggests a change that has an effect from
>Windows only, not from Cygwin).


To me, a change in semantics is not something to quibble with if the 
current semantics are the result of a bug.  There needs to be consistency 
in handling the "link to an executable file without the extension specified" 
case and this is what I see (and originally saw) as the bug.  If the solution 
to this bug is to allow a program name to be specified without '.exe' as the 
source but still have the link succeed, then the issue with symlinks created 
this way needs to be addressed as well.  The converse is left as a thought
exercise for the reader.

Unless you think there is some significant point in your original report 
that hasn't been discussed, I'd say we've covered the relevant bases on 
this topic.

Thanks for the report.

--
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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/