except mv(1) and cp(1) are both "FROM" and then "TO", but ln is backwards from thi, it is "TO" then "FROM", the least the command could do is put these in the correct order.

> it is a one-time effort to learn the order

Opinion, do you want proof that people can't learn this, because they haven't.

> The synopsis is already complex and confusing enough:

Opinion, it is as complex as it allows, sounds like you are saying "LN Sucks, we really need 4 commands which are all simpler", sure okay we can have another command, but doing the right thing ALWAYS takes precedence over "I have an opinion"

> what happens if another (malicious?) user B creates LINK_TARGET while user A is typing the command?

While typing before entering? Then it doesn't matter if they are reversed since the command would still fail because both exist, that should result in the only real failure. I'm not suggesting removing the error in all cases.

> $ ln -nsvf somename othername

WTF, yeah let's tell everyone that gets this wrong to delete the file they want to link, that's a genius idea.

On Fri, Nov 26, 2021 at 12:02 AM Bernhard Voelker <mail@bernhard-voelker.de> wrote:

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