ln and mkshortcut inconsistent in handling of .exe extension

ln and mkshortcut inconsistent in handling of .exe extension

[Matt Swift]

The following shell transcript demonstrates that `ln' does not handle
the .exe extension gracefully, like mkshortcut does.

I believe graceful behavior would require the following changes:

  1) `ln' would not give the two errors below when trying to create
     "hardlink-to-base" and "hardlink-to-base.exe": the target
     ("program") should silently have the .exe extension added.  I do
     not know whether there should be a warning in this case, or
     whether the .exe extension should be added to the link-name,
     perhaps with a warning.

  2) The files "symlink-to-base" "symlink-to-base.exe" should have the
     .exe extension silently added to the Windows shortcut target: at
     present, the files are not valid Windows shortcuts (they appear
     to Windows Explorer as a shortcut, but have an empty "Target"
     which can not be altered in the usual way; the Comment field is
     correct).  This behavior would match `mkshortcut''s, which adds
     the .exe extension to the Target when it is not supplied on the
     command-line (what appeared on the command-line appears verbatim
     in the Comment field, however).



    [vav] test> ls -l
    total 909
    -rwxr-xr-x    1 swift    Administ   930304 Sep 29 13:05 program.exe
    [vav] test> ln -s program symlink-to-base
    [vav] test> ln -s program.exe symlink-to-full
    [vav] test> ln -s program symlink-to-base.exe
    [vav] test> ln -s program.exe symlink-to-full.exe

    [vav] test> ln program hardlink-to-base
    ln: creating hard link `hardlink-to-base' to `program': No such file or directory
    [vav] test> ln program.exe hardlink-to-full
    [vav] test> ln program hardlink-to-base.exe
    ln: creating hard link `hardlink-to-base.exe' to `program': No such file or directory
    [vav] test> ln program.exe hardlink-to-full.exe

    [vav] test> mkshortcut program
    [vav] test> mkshortcut program.exe

    [vav] test> ls -l
    total 2729
    -rwxr-xr-x    3 swift    Administ   930304 Sep 29 13:05 hardlink-to-full
    -rwxr-xr-x    3 swift    Administ   930304 Sep 29 13:05 hardlink-to-full.exe
    -rwxr-xr-x    3 swift    Administ   930304 Sep 29 13:05 program.exe
    -rwxrwxr-x    1 swift    Administ      661 Sep 29 13:38 program.exe.lnk
    -rwxrwxr-x    1 swift    Administ      433 Sep 29 13:37 program.lnk
    lrwxrwxrwx    1 swift    Administ       94 Sep 29 13:36 symlink-to-base -> program
    lrwxrwxrwx    1 swift    Administ       94 Sep 29 13:36 symlink-to-base.exe -> program
    lrwxrwxrwx    1 swift    Administ      102 Sep 29 13:36 symlink-to-full -> program.exe
    lrwxrwxrwx    1 swift    Administ      102 Sep 29 13:36 symlink-to-full.exe -> program.exe
    [vav] test> 

    [vav] test> hostname; uname -a
    vav
    CYGWIN_NT-5.1 vav 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin
    [vav] test> type ln
    ln is hashed (/usr/bin/ln)
    [vav] test> cygcheck -f /usr/bin/ln
    fileutils-4.1-2
    [vav] test> cygcheck -c fileutils
    Cygwin Package Information
    Package              Version        Status
    fileutils            4.1-2          OK

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

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

[Larry Hall]

At 02:23 PM 9/29/2003, Matt Swift you wrote:
>  2) The files "symlink-to-base" "symlink-to-base.exe" should have the
>     .exe extension silently added to the Windows shortcut target: at
>     present, the files are not valid Windows shortcuts (they appear
>     to Windows Explorer as a shortcut, but have an empty "Target"
>     which can not be altered in the usual way; the Comment field is
>     correct).  This behavior would match `mkshortcut''s, which adds
>     the .exe extension to the Target when it is not supplied on the
>     command-line (what appeared on the command-line appears verbatim
>     in the Comment field, however).


'ln' and 'mkshortcut' have different behavior for a reason.  See 
<http://cygwin.com/cygwin-ug-net/using-effectively.html#AEN1516>.
The difference is why 'mkshortcut' exists.  Otherwise, we'd just have
'ln' (which is all we had for quite some time until the need for 
different behavior was realized).



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

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

[Christopher Faylor]

On Mon, Sep 29, 2003 at 02:23:23PM -0400, Matt Swift wrote:
>The following shell transcript demonstrates that `ln' does not handle
>the .exe extension gracefully, like mkshortcut does.

Correct.  It is not intended to.
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

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

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

[Matt Swift]

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

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 and 'ln' (hardlink) defaulted to a target of
"foo.exe" when the supplied target "foo" doesn't exist?  


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

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

[Larry Hall]

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
>experiment.
>
>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 
missing?


>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 
investigate further.



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

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

[Matt Swift]

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

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

[Larry Hall]

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/

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

[Christopher Faylor]

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/