bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

[Kamil Dudka]

On Friday, November 26, 2021 12:10:36 AM CET Warren Parad wrote:
> 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.

Seriously, such experiments do not belong to the system implementation of 
ln(1).  If you really need this behavior, you can implement it as a shell 
function.  Sooner or later you will regret that you did it.

Kamil