bug#20354: [feature request] ln with command line arguments in reverse order
On Sun, Apr 19, 2015 at 8:27 AM, Ma Jiehong wrote:
> The translation in the help message is not wrong, and "TARGET" and
> "LINK_NAME" are used.
>
> The issue simply is with the mental model made when approaching the "ln"
> command. In French, the usual way to say when creating a link is: "Je vais
> créer une lien A pointant vers B", which can be literally translated as "I
> will create a link named A pointing on B".
>
> This is wrong, as it should be more something like "Je vais lier A et B"
> would be better ("I will link A and B"), but A and B are implicitly already
> existing when thinking about this sentence.
>
> Checking the help message of "ln" clarifies this, but it's counter-intuitive
> in French, and most people tend to make a mistake in the order of argument
> of "ln", and then re-do it with arguments in reverse order. (me first, even
> though I use the cli everyday...)
The issue is not French-specific.
There are two fundamentally different cases:
- hard link: "I will link A and B"
- symlinks: "I will create a symlink B pointing at A"
bug#20354: [feature request] ln with command line arguments in reverse order
The translation in the help message is not wrong, and "TARGET" and
"LINK_NAME" are used.
The issue simply is with the mental model made when approaching the "ln"
command. In French, the usual way to say when creating a link is: "Je
vais créer une lien A pointant vers B", which can be literally
translated as "I will create a link named A pointing on B".
This is wrong, as it should be more something like "Je vais lier A et B"
would be better ("I will link A and B"), but A and B are implicitly
already existing when thinking about this sentence.
Checking the help message of "ln" clarifies this, but it's
counter-intuitive in French, and most people tend to make a mistake in
the order of argument of "ln", and then re-do it with arguments in
reverse order. (me first, even though I use the cli everyday…)
Is that clearer?
Perhaps French people are just doomed to have an issue with the "ln"
command.
J.
On 17/04/15 13:12, Bernhard Voelker wrote:
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
tag 20354 wontfix close 20354 stop On 18/04/15 07:09, Bernhard Voelker wrote: > On 04/17/2015 04:52 PM, Erik Auerswald wrote: >> On Fri, Apr 17, 2015 at 01:45:02PM +0100, Pádraig Brady wrote: >>> How I think about it is: >>> >>> cp [OPTION] EXISTING NEW >>> mv [OPTION] EXISTING NEW >>> ln [OPTIONS] EXISTING NEW >> >> That's good wording. > > IMO there's no gain if the operand names are the same, because > then the users would have to know the tool even better. Such > distinction makes the users help to remember how the tool works. > So at least for ln(1), the word LINK_NAME is perfect. > > FWIW this was Jim's change to improve the wording back in 1998: > > http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=519365bb089c I agree. NEW above is ambiguous for example, as DEST can already exist. Also EXISTING in the ln case is not accurate, since the target doesn't need to exist. I was just indicating how I summarise the usual use case for these in my mind, but can't think of any improvement to the more accurate existing wording. cheers, Pádraig.
bug#20354: [feature request] ln with command line arguments in reverse order
On 04/17/2015 04:52 PM, Erik Auerswald wrote: > On Fri, Apr 17, 2015 at 01:45:02PM +0100, Pádraig Brady wrote: >> How I think about it is: >> >> cp [OPTION] EXISTING NEW >> mv [OPTION] EXISTING NEW >> ln [OPTIONS] EXISTING NEW > > That's good wording. IMO there's no gain if the operand names are the same, because then the users would have to know the tool even better. Such distinction makes the users help to remember how the tool works. So at least for ln(1), the word LINK_NAME is perfect. FWIW this was Jim's change to improve the wording back in 1998: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=519365bb089c Have a nice day, Berny
bug#20354: [feature request] ln with command line arguments in reverse order
On Fri, Apr 17, 2015 at 03:07:50PM +0200, Bernhard Voelker wrote: > On 04/17/2015 02:45 PM, Pádraig Brady wrote: > > ln [OPTIONS] EXISTING NEW > > I stilll think this is a translation issue. > And I don't think the synopsis has to look the same as for > cp and mv. If you really want it to be changed, What about > > ln [OPTIONS] LINK_TARGET LINK_NAME > > ? IMHO changing TARGET to LINK_TARGET does not help. Why should the synopsis for similar commands look differently? cp -l SOURCE DEST ln TARGET LINK_NAME cp -s SOURCE DEST ln -s TARGET LINK_NAME Perhaps new users should be told to stay away from ln and always use cp? *SCNR* Anyway, I have seen the confusion about ln usage by inexperienced users and just wanted to chime in. The original posters suggestion of a --reverse-order option would make matters worse IMHO. Thanks, Erik
bug#20354: [feature request] ln with command line arguments in reverse order
On Fri, Apr 17, 2015 at 01:45:02PM +0100, Pádraig Brady wrote: > On 17/04/15 12:45, Erik Auerswald wrote: > > On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote: > >> 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 > >>> [...] > >> output would be the better way. > > > > I'd say that using TARGET instead of SOURCE creates confusion that would be > > avoided by using SOURCE and DEST as with cp and mv. > > Not really, as one could still consider that > DEST was the destination of a symlink. > > How I think about it is: > > cp [OPTION] EXISTING NEW > mv [OPTION] EXISTING NEW > ln [OPTIONS] EXISTING NEW That's good wording. Thanks, Erik
bug#20354: [feature request] ln with command line arguments in reverse order
On 04/17/2015 02:45 PM, Pádraig Brady wrote: ln [OPTIONS] EXISTING NEW I stilll think this is a translation issue. And I don't think the synopsis has to look the same as for cp and mv. If you really want it to be changed, What about ln [OPTIONS] LINK_TARGET LINK_NAME ? Have a nice day, Berny
bug#20354: [feature request] ln with command line arguments in reverse order
On 17/04/15 12:45, Erik Auerswald wrote: > On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote: >> 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. >>> [...] >>> 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. > > If you do not know the original order beforehand, you do not know the > --reverse-order either. IMHO this option does not help. > >> The situation would be better if the target would be an operand to that >> option, similar to mv's --target-directory=DIRECTORY option. > > Careful here, --target-directory specifies a DESTination, while ln's TARGET > means SOURCE. > >> 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. > > I'd say that using TARGET instead of SOURCE creates confusion that would be > avoided by using SOURCE and DEST as with cp and mv. Not really, as one could still consider that DEST was the destination of a symlink. How I think about it is: cp [OPTION] EXISTING NEW mv [OPTION] EXISTING NEW ln [OPTIONS] EXISTING NEW cheers, Pádraig.
bug#20354: [feature request] ln with command line arguments in reverse order
On Fri, Apr 17, 2015 at 01:12:01PM +0200, Bernhard Voelker wrote: > 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. > > [...] > > 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. If you do not know the original order beforehand, you do not know the --reverse-order either. IMHO this option does not help. > The situation would be better if the target would be an operand to that > option, similar to mv's --target-directory=DIRECTORY option. Careful here, --target-directory specifies a DESTination, while ln's TARGET means SOURCE. > 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. I'd say that using TARGET instead of SOURCE creates confusion that would be avoided by using SOURCE and DEST as with cp and mv. Thanks, Erik
bug#20354: [feature request] ln with command line arguments in reverse order
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
Hello, 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". This is annoying, because it is quite the opposite, and either people make the mistake and retry, or need to read the "ln --help" each time, or create a way to remember what is the right order, but in the end tend to confuse, and make a mistake too. 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 This new option would ensure that no script or tool depending on "ln" would break, while allowing some people to use it this way. Jiehong
