On 11/25/21 18:53, Warren Parad wrote:
> It is too frequent a problem to know which is the correct order of TARGET
> and LINK_NAME.
I disagree: it is a one-time effort to learn the order ... similar as
for mv(1) and cp(1).
> Since the command already believes that it can't create a link to a file
> which already exists (and for hard links that the TARGET must also exist),
> instead of complaining, the command should just switch the order of the
> parameters.
The synopsis is already complex and confusing enough:
Usage: ln [OPTION]... [-T] TARGET LINK_NAME
or: ln [OPTION]... TARGET
or: ln [OPTION]... TARGET... DIRECTORY
or: ln [OPTION]... -t DIRECTORY TARGET...
and especially surprising if LINK_NAME is a directory name which the caller
wasn't aware of. Letting ln(1) automagically swap the parameters if LINK_NAME
exists simply adds more confusion and opens maybe a big race window:
what happens if another (malicious?) user B creates LINK_TARGET while user A
is typing the command?
Personally, I recommend the following option combination which results in
less surprises (see other cases below):
$ ln -nsvf somename othername
Especially when creating symlinks, I prefer to get an error early rather than
ending up with a symlink with a name or location I never would have expected.
Have a nice day,
Berny
