[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
bug#20354: [feature request] ln with command line arguments in reverse order, Ma Jiehong, 2015/04/19