Created links are ambiguous
mateuszviste I don't understand the problem here. If you have both a COM and an EXE, how is the system supposed to know which one you want to run? It's up to you to specify it. If you don't, then COM will be picked, because of legacy priorities. adding a COM/EXE information to the link itself does not have any value.
the SvarCOM link is more a "link to directory" rather than "link to file". Ie. it says "for such command look into this directory to find a match". Perhaps the documentation could be clarified, if it's not obvious enough.
mateuszviste I think I understand the scenario: you have a package that have both files:
C:\INFOZIP\ZIP.COM
C:\INFOZIP\ZIP.EXE
...and you would like that the global "ZIP" command execute ZIP.EXE instead of ZIP.COM.
That is definitely a feature ("link to file"). Another question would be whether this is actually a practical need?
Reply To mateuszviste
I think I understand the scenario: you have a package that have both files: C:\INFOZIP\ZIP.COM C:\INFOZIP\ZIP.EXE ...and you would like that the global "ZIP" command execute ZIP.EXE instead of ZIP.COM.
That's correct.
That is definitely a feature ("link to file"). Another question would be whether this is actually a practical need?
What is the practical need of having links at all, when we already have aliases or macros in DOSKEY or TODDY? ;-) That came to my mind yesterday evening...
(Links take disk space, 1 cluster per link. Aliases/macros take precious RAM, I know.)
I consider this a bug, although it's also a kind of feature request.
Imagine the following:
It's not uncommon to have progname.com and progname.exe in one package.
I think, it would be better to change the links to also include the extension .COM or .EXE.
This would also allow links like: NC.LNK -> C:\VC\VC.COM