2nd time 'ln add' for the same linkname is a no-op
mateuszviste Consider the following: 1. ln add fed c:\progs\fed -> a link to c:\progs\fed\fed.exe will be created 2. ln add fed c:\ -> outputs a blank line, the link is not updated LN command should update the link accordingly. Probably after displaying the current link target and prompting for confirmation.
Uh, complicated (displaying current, confirmation, proceeding, etc).
It should have output an error message. This was a regression. fixed in rev 1046.
Or add an 'update' or 'change' sub-command. -- It might also be the right time now to rename the 'add' sub-command to 'create'.
But is it really semantically wrong? I like add because it's fast to type :)
Another 'by the way': DOS is not UNIX. So, a successful command like 'add' or 'del' should display a result. :-)
del c:\autoexec.bat does not display any result.
Reply To mateuszviste
Consider the following: 1. ln add fed c:\progs\fed -> a link to c:\progs\fed\fed.exe will be created 2. ln add fed c:\ -> outputs a blank line, the link is not updated LN command should update the link accordingly. Probably after displaying the current link target and prompting for confirmation.
Uh, complicated (displaying current, confirmation, proceeding, etc).
That's why I asked in: What is the practical need of having links at all, when we already have aliases or macros in DOSKEY or TODDY? \ (Links take disk space, 1 cluster per link. Aliases/macros take precious RAM, I know.)
Do we really need to 'duplicate' this feature in SvarCOM? You wanted SvarCOM lean (and mean). ;-)
It should have output an error message. This was a regression. fixed in rev 1046.
Or add an 'update' or 'change' sub-command. -- It might also be the right time now to rename the 'add' sub-command to 'create'.
But is it really semantically wrong? I like add because it's fast to type :)
No, it's not wrong. I don't remember exactly what I thought then.
A variant similar to the SET command:
Now, that I wrote it, I see no need to have the 'set' sub-command. Simply use 'ln' or rename 'ln' to 'lnset'.
Another 'by the way': DOS is not UNIX. So, a successful command like 'add' or 'del' should display a result. :-)
del c:\autoexec.bat does not display any result.
You got me. Darn MS boys! :-D
mateuszviste Reply To bttr
That's why I asked in: What is the practical need of having links at all, when we already have aliases or macros in DOSKEY or TODDY? \ (Links take disk space, 1 cluster per link. Aliases/macros take precious RAM, I know.)
Depends of the use case I guess. SvarCOM provides a primitive mechanism for links. It is very simple and not cluster-efficient, but comes for free with SvarCOM (consumes no RAM at all). More demanding users might prefer more sophisticated solutions like LINK/LN or DOSKEY macros etc. The approach is similar to the input shell service: SvarCOM provides a primitive 1-command history, if someone needs more then there are specialized tools (TODDY, DOSKEY).
BTW aliases are not supported in SvarCOM.
Do we really need to 'duplicate' this feature in SvarCOM? You wanted SvarCOM lean (and mean). ;-)
I know that am I not entirely consistent on this point. :) (esp. since MS-DOS never came with anything similar to links)
But indeed, I may consider dropping the links feature if it occurs that there is no space in SvarCOM for other more important things (and no existing users complain). For now there is still some 4K of space left before the 64K limit is hit, so there's a little bit margin before cuts are needed.
A variant similar to the SET command: * to add or update a link: ln set foo=c:\progs\foo (could ask for confirmation, if link already exists) * to delete a link: ln set foo= * to see existing links: ln set or ln set pattern
Could be an interesting alternative, yes, as it would be closer to something users already know... But the code to handle would be also a little more complex (and bigger). I did it this way simply because it was the easiest way forward, as it allows to leverage already existing code without too much troubles.
Reply To mateuszviste
Reply To bttr
That's why I asked in: What is the practical need of having links at all, when we already have aliases or macros in DOSKEY or TODDY? \ (Links take disk space, 1 cluster per link. Aliases/macros take precious RAM, I know.)
Depends of the use case I guess. SvarCOM provides a primitive mechanism for links. It is very simple and not cluster-efficient, but comes for free with SvarCOM (consumes no RAM at all). More demanding users might prefer more sophisticated solutions like LINK/LN or DOSKEY macros etc. The approach is similar to the input shell service: SvarCOM provides a primitive 1-command history, if someone needs more then there are specialized tools (TODDY, DOSKEY).
I see.
BTW aliases are not supported in SvarCOM.
I know, thanks.
Do we really need to 'duplicate' this feature in SvarCOM? You wanted SvarCOM lean (and mean). ;-)
I know that am I not entirely consistent on this point. :) (esp. since MS-DOS never came with anything similar to links) But indeed, I may consider dropping the links feature if it occurs that there is no space in SvarCOM for other more important things (and no existing users complain). For now there is still some 4K of space left before the 64K limit is hit, so there's a little bit margin before cuts are needed.
I see.
A variant similar to the SET command: * to add or update a link: ln set foo=c:\progs\foo (could ask for confirmation, if link already exists) * to delete a link: ln set foo= * to see existing links: ln set or ln set pattern
Could be an interesting alternative, yes, as it would be closer to something users already know... But the code to handle would be also a little more complex (and bigger). I did it this way simply because it was the easiest way forward, as it allows to leverage already existing code without too much troubles.
ACK
I close this ticket now, because the original issues has been solved.
Consider the following:
LN command should update the link accordingly. Probably after displaying the current link target and prompting for confirmation.
Or add an 'update' or 'change' sub-command. -- It might also be the right time now to rename the 'add' sub-command to 'create'.
Another 'by the way': DOS is not UNIX. So, a successful command like 'add' or 'del' should display a result. :-)