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

[Matt Swift <swift at alum dot mit dot edu>]

>> "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

(1) the independent documentation of how .exe extensions are handled
    (user guide 3.4.3) and how symlinks are handled (3.5, 3.7.5) does
    not address their conjunction, a case which does not work as
    expected.  The documentation on .exe extensions says that
    "install" and "strip" are the exceptions to transparent handling
    of .exe extensions.  'ln' should be included, and this case should
    be mentioned or cross-referenced in 3.5 and 3.7.5 as well.

(2) instead of changing documentation per (1), it is reasonable to
    change the behavior of 'ln -s' so that the file it creates in the
    case under discussion is not only a Cygwin symbolic link but also
    a valid Windows Shortcut.  NOT a full-fledged Windows Shortcut
    with icon and so on, of the kind mkshortcut creates, and the kind
    which you have repeatedly mistaken me to mean -- but simply a
    valid one, which points to the expected file, just like ALL the
    files that 'ln -s' creates EXCEPT in the particular case that the
    target's name is an executable without an .exe extension.  The
    change I propose does not change how the files 'ln -s' creates
    function as Cygwin symlinks; it changes how a certain small
    anomalous category of files that 'ln -s' creates function as
    Windows Shortcuts, in a way that brings this case into conformity
    with the others it creates.  When Cygwin follows a symlink, it
    examines the pathname that appears in the "Comment" field if you
    examine the file as a Windows Shortcut.  When Windows follows a
    shortcut, it examines the contents of the "Target" field.  'ln'
    always puts the correct value in "Comment" and USUALLY puts the
    correct value in "Target", but not in the case under discussion.
    Wishing that 'ln' always put the right thing in both places is NOT
    wishing that ln were mkshortcut, it's wishing that ln behave
    consistently with all other Cygwin programs ("install" and "strip"
    being the documented exceptions), which are indifferent to whether
    .exe extensions are omitted or explicitly given.


    >> 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).




--
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/