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

Previous Next

To reply to this bug, email your comments to 52115 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Warren Parad <wparad <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME
 already exists
Date: Thu, 25 Nov 2021 18:53:49 +0100

[Message part 1 (text/plain, inline)]

It is too frequent a problem to know which is the correct order of TARGET
and LINK_NAME.

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.

[Message part 2 (text/html, inline)]

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

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

From: Warren Parad <wparad <at> gmail.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 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:10:36 +0100

[Message part 1 (text/plain, inline)]

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 <at> 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
>

[Message part 2 (text/html, inline)]

Message #14 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>
Cc: 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:32:01 +0100

On 11/26/21 00:10, Warren Parad wrote:
> On Fri, Nov 26, 2021 at 12:02 AM Bernhard Voelker <mail <at> bernhard-voelker.de <mailto:mail <at> bernhard-voelker.de>> wrote:
>> 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".

That is my opinion, correct.
Yet there's also standardization (POSIX) and 40+ years of known behavior.  Adding functionality has to be
well-thought and must not contradict any existing usage, nor open doors for more surprises to users.
Finally, there's compatibility to other implementations to consider.

>> 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.

That's the point: the outcome would greatly depend on whether LINK_TARGET is created as regular file
or as a directory.  And no, one cannot predict when another process is modifying the file system.
IMO this is more surprising and therefore inconvenient than to get an error message if the
user missed to put TARGET and LINK_NAME in the correct order.

Have a nice day,
Berny

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

From: Kamil Dudka <kdudka <at> redhat.com>
To: Warren Parad <wparad <at> gmail.com>
Cc: 52115 <at> debbugs.gnu.org, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 bug-coreutils <at> 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 08:25:28 +0100

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Warren Parad <wparad <at> gmail.com>
Cc: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Sat, 27 Nov 2021 00:41:07 -0800

On 11/25/21 15:10, 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"

No, ln is exactly like mv and cp here: the source is the first argument, 
and the destination is the second.

If this isn't clear, perhaps we should make the documentation clearer; 
but we shouldn't change ln's behavior, as many people and programs rely 
on the current behavior, and the current behavior is more logical once 
you understand how file systems work.

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

From: Bob Proulx <bob <at> proulx.com>
To: Warren Parad <wparad <at> gmail.com>
Cc: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Sun, 28 Nov 2021 18:07:02 -0700

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.

But that is not correct.  The order for ln is the same as for cp and
mv in that the target getting created is the right side argument.

(Unless the -t or -T option is used to do it differently by explicit
syntax request.  Unless no target is specified in which case dot is
assumed.  I admit those two "unless" cases complicate the original
simplicity.  But the normal case is to create the right side argument
as the target of the command.)

> >  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 target getting created is the right side argument.  If that is not
clear from the documentation then improving the documentation is
always good.

Let me say with some confidence that if the order were changed to
create the left argument that people would be very upset that cp and
mv created the right side argument but ln created a left side
argument!

Bob

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

From: Chris Elvidge <celvidge001 <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>, Warren Parad <wparad <at> gmail.com>
Cc: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 09:58:50 +0000

On 29/11/2021 01:07 am, Bob Proulx wrote:
> 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.
> 
> But that is not correct.  The order for ln is the same as for cp and
> mv in that the target getting created is the right side argument.
> 
> (Unless the -t or -T option is used to do it differently by explicit
> syntax request.  Unless no target is specified in which case dot is
> assumed.  I admit those two "unless" cases complicate the original
> simplicity.  But the normal case is to create the right side argument
> as the target of the command.)
> 
>>>   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 target getting created is the right side argument.  If that is not
> clear from the documentation then improving the documentation is
> always good.
> 
> Let me say with some confidence that if the order were changed to
> create the left argument that people would be very upset that cp and
> mv created the right side argument but ln created a left side
> argument!
> 
> Bob
> 
> 
> 
> 

Windows mklink command already does this - yes, it's annoying.

-- 

Chris Elvidge

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

From: Ulf Zibis <Ulf.Zibis <at> gmx.de>
To: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 11:34:33 +0100

Am 27.11.21 um 09:41 schrieb Paul Eggert:
> On 11/25/21 15:10, 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"
>
> No, ln is exactly like mv and cp here: the source is the first argument, and the destination is the second.
The problem is the possible confusion between "target" as result of the command and as link target.

> If this isn't clear, perhaps we should make the documentation clearer; but we shouldn't change ln's behavior, as many people and programs rely on the current behavior, and the current behavior is more logical once you understand how file systems work.
Agreed.
I would like to change the order of the forms from:
Usage: ln [OPTION]... [-T] TARGET LINK_NAME
  or:  ln [OPTION]... TARGET
  or:  ln [OPTION]... TARGET... DIRECTORY
  or:  ln [OPTION]... -t DIRECTORY TARGET...
In the 1st form, create a link to TARGET with the name LINK_NAME.
In the 2nd form, create a link to TARGET in the current directory.
In the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
Create hard links by default, symbolic links with --symbolic.
By default, each destination (name of new link) should not already exist.
When creating hard links, each TARGET must exist.  Symbolic links
can hold arbitrary text; if later resolved, a relative link is
interpreted in relation to its parent directory.
to:
Usage: ln [OPTION]... TARGET
  or:  ln [OPTION]... [-T] TARGET LINK_NAME
  or:  ln [OPTION]... TARGET... DIRECTORY
  or:  ln [OPTION]... -t DIRECTORY TARGET...
1st form: Create a link to TARGET with same name in the current directory.
2nd form: Create a link to TARGET with the name LINK_NAME.
3rd and 4th forms: Create links to each TARGET in DIRECTORY.
Create hard links by default, symbolic links with --symbolic.
By default, each destination (name of new link) should not already exist.
When creating hard links, each TARGET must exist.  Symbolic links
can hold arbitrary text; if later resolved, a relative link is
interpreted in relation to its parent directory.

I think, for beginners it would be less confusing, if the most simple form would be the first.

Additionally we could add "with the same name" in the than 1st form.

Additionally we could shorten "In the 1st form," to "1st form:".

Also for me the existence of the 3rd for is the most confusing, as it enforces the perplexing -T option.

-Ulf

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ulf Zibis <Ulf.Zibis <at> gmx.de>
Cc: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 11:07:55 -0800

On 11/29/21 02:34, Ulf Zibis wrote:
> I think, for beginners it would be less confusing, if the most simple 
> form would be the first.

Unfortunately the simple form "ln TARGET" is quite rarely used, so 
putting it first is likely to confuse beginners even more than what we 
have already. Come to think of it, perhaps we should put the simple form 
last instead of 2nd.

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

From: Chris Elvidge <celvidge001 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Ulf Zibis <Ulf.Zibis <at> gmx.de>
Cc: 52115 <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 20:01:33 +0000

On 29/11/2021 07:07 pm, Paul Eggert wrote:
> On 11/29/21 02:34, Ulf Zibis wrote:
>> I think, for beginners it would be less confusing, if the most simple 
>> form would be the first.
> 
> Unfortunately the simple form "ln TARGET" is quite rarely used, so 
> putting it first is likely to confuse beginners even more than what we 
> have already. Come to think of it, perhaps we should put the simple form 
> last instead of 2nd.
> 

I use 'ln -s "source"' quite a lot for linking into e.g. /usr/local/bin 
from my own $HOME/bin.

The real problem could be with the terminology.
'ln [options] TARGET [LINK_NAME]'; the TARGET is really the source, 
which obviously must exist. A TARGET is really something you aim at.

Perhaps it should be changed to 'ln [options] source [link]'


-- 

Chris Elvidge

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

From: Bob Proulx <bob <at> proulx.com>
To: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 15:06:26 -0700

Chris Elvidge wrote:
> Paul Eggert wrote:
> > Ulf Zibis wrote:
> > > I think, for beginners it would be less confusing, if the most
> > > simple form would be the first.
> > 
> > Unfortunately the simple form "ln TARGET" is quite rarely used, so
> > putting it first is likely to confuse beginners even more than what we
> > have already. Come to think of it, perhaps we should put the simple form
> > last instead of 2nd.

+1 for putting it last.

> I use 'ln -s "source"' quite a lot for linking into e.g. /usr/local/bin from
> my own $HOME/bin.

It defaults to "." as the target in that case.  I never liked that it
was allowed to be optional as I think it makes things much more
confusing than the two characters saved.

> The real problem could be with the terminology.
> 'ln [options] TARGET [LINK_NAME]'; the TARGET is really the source, which
> obviously must exist. A TARGET is really something you aim at.

Mostly agree.  With symbolic links the symlink contains a string.  The
string could be pretty much anything.  By convention it contains the
path to another file.  (Or to another special file.  Everything is a
file.)  But it is also used to contain a small bit of information in
other cases.  Such as for lockfiles and other uses.  Therefore source
isn't quite right.  But maybe it is good enough.  Because CONTENTS
seems less good even if perhaps more accurate.

> Perhaps it should be changed to 'ln [options] source [link]'

mv calls it SOURCE and DEST.  cp calls it SOURCE and DEST.  Perhaps ln
should also call it SOURCE and DEST too for consistency?

    cp [OPTION]... [-T] SOURCE DEST
    mv [OPTION]... [-T] SOURCE DEST
    ln [OPTION]... [-T] SOURCE DEST

I like the consistency of that.

Although I don't like that -T is not apparently an OPTION.  It's not?
Why not?  Shouldn't that synopsis form simply be these?

    cp [OPTION]... SOURCE DEST
    mv [OPTION]... SOURCE DEST
    ln [OPTION]... SOURCE DEST

Bob

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

From: Rainer Canavan <coreutils <at> canavan.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists
Date: Tue, 30 Nov 2021 00:20:12 +0100

On November 27, 2021 9:41:07 AM GMT+01:00, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>On 11/25/21 15:10, 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"
>
>No, ln is exactly like mv and cp here: the source is the first argument, 
>and the destination is the second.
>
>If this isn't clear, perhaps we should make the documentation clearer; 
>but we shouldn't change ln's behavior, as many people and programs rely 
>on the current behavior, and the current behavior is more logical once 
>you understand how file systems work.


Just as an anecdote, for me personally the confusion about source and destination had its primary source in the way ls -l displays links as dest -> src. Since the direction of that arrow has been the same since basically forever, I don't think that should be changed, so I don't have any suggestions how this could possibly be "fixed".

Regards,

Rainer 

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

From: Bob Proulx <bob <at> proulx.com>
To: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 16:24:24 -0700

Bob Proulx wrote:
> With symbolic links the symlink contains a string.  The string could
> be pretty much anything.

The more I think about it the more I think it should say CONTENT
rather than either TARGET or SOURCE.  Because it is actually setting
the content of the symbolic link.  Therefore that seems the most
accurate.  Although VALUE also seems to have merit.

    ln [OPTION]... CONTENT DEST

Bob

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bob Proulx <bob <at> proulx.com>
Cc: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Mon, 29 Nov 2021 22:34:38 -0800

On 11/29/21 14:06, Bob Proulx wrote:
> mv calls it SOURCE and DEST.  cp calls it SOURCE and DEST.  Perhaps ln
> should also call it SOURCE and DEST too for consistency?

That's what ln did long ago, but that wording was deemed too confusing. 
Here's where we changed it to use something more like the current wording:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=519365bb089cf90bdc780c37292938f42019c7ea

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Tue, 30 Nov 2021 10:39:45 +0100

On Nov 29 2021, Bob Proulx wrote:

> The more I think about it the more I think it should say CONTENT
> rather than either TARGET or SOURCE.  Because it is actually setting
> the content of the symbolic link.

A hard link doesn't have content.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Bob Proulx <bob <at> proulx.com>
To: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Tue, 30 Nov 2021 23:39:00 -0700

Andreas Schwab wrote:
> Bob Proulx wrote:
> > The more I think about it the more I think it should say CONTENT
> > rather than either TARGET or SOURCE.  Because it is actually setting
> > the content of the symbolic link.
> 
> A hard link doesn't have content.

But we are talking about symbolic links which do have content.

Bob

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

From: Bob Proulx <bob <at> proulx.com>
To: 52115 <at> debbugs.gnu.org, 52115-submitter <at> debbugs.gnu.org
Subject: Re: bug#52115: Suggestion: LN command should swap TARGET and
 LINK_NAME if LINK_NAME already exists
Date: Tue, 30 Nov 2021 23:41:50 -0700

Paul Eggert wrote:
> Bob Proulx wrote:
> > mv calls it SOURCE and DEST.  cp calls it SOURCE and DEST.  Perhaps ln
> > should also call it SOURCE and DEST too for consistency?
> 
> That's what ln did long ago, but that wording was deemed too confusing.
> Here's where we changed it to use something more like the current wording:
> 
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=519365bb089cf90bdc780c37292938f42019c7ea

This just proves that there is no perfect solution.  It's a flip-flop
with either state having inperfections.

My first thought was how humorous this situation is that due to
complaints about the documentation we would be lead in a circle back
to the beginning when this was changed previously due to complaints
about the documentation.

Bob

Previous Next

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