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

[Pádraig Brady]

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.