bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20354: [feature request] ln with command line arguments in reverse o


From: Bernhard Voelker
Subject: bug#20354: [feature request] ln with command line arguments in reverse order
Date: Fri, 17 Apr 2015 13:12:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 04/17/2015 10:39 AM, Ma Jiehong wrote:
Currently, 'cp', 'mv' and 'ln' share the same basic syntax, that is to say the 
following:

cp [OPTION]  SOURCE DEST
mv [OPTION] SOURCE DEST
ln [OPTIONS] TARGET LINK_NAME

Which is the same exact rule, and is consistent.

While this is perfect for 'cp' and 'mv', I claim that it shouldn't be the case 
for 'ln'.

This analysis comes from experience, a discussion from linuxfr.org (French),
 and also from a design point of view.

These 3 operations are verbs, and we could read those commands as "copy source
 to destination", "move source to destination" and "link source to destination".

But a big part of the French population at least, would tend to read the
link verb as "create a link (named) A pointing on B".

My French from school is a bit rusty, but are you sure this isn't a problem of
the translation?  I mean, the wording "link source to destination" is somehow
correct:  the SOURCE is the (probably) already existing TARGET, where the
resulting symlink (LINK_NAME/DEST) will resolve to.  Therefore one could also
see it like "ln ... SOURCE DEST", because there is only SOURCE where several
symbolic links point to.  But TARGET and LINK_NAME is a much clearer term.

> Therefore, I would like to offer the possibility to use "ln" with arguments
> in the reverse order, given an option, say "--reverse-order/-R".
>
> In this case, the command would act like this:
> ln --reverse-order LINK_NAME TARGET

Adding an option to reverse the two may have it's merits, but I guess this
extra flexibility would only confuse the users even more.
The situation would be better if the target would be an operand to that
option, similar to mv's --target-directory=DIRECTORY option.
However, I think this would just bloat the code for not much new functionality,
and I'm convinced that a good translation for TARGET and LINK_NAME in --help
output would be the better way.

Have a nice day,
Berny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]