GNU bug report logs - #52115
Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

Previous Next

Full log

Message #8 received at 52115 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Warren Parad <wparad <at> gmail.com>, 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Fri, 26 Nov 2021 00:02:46 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.