Re: feature request: better intuitive syntax LINK=TARGET

[Kaz Kylheku (Coreutils)]

On 2020-06-24 19:35, Andrej Surkov wrote:
> Hi all!
>
>    ln syntax is very uncertain - every time I use ln I'm confused what 
> is
>    correct "ln -s LINK TARGET" or "ln -s TARGET LINK"! Of cause I can
>    check man ln or ln --help, but what if we add unambiguous syntax, 
> for
>    example
>
>    ln -s LINK=TARGET

mv existing new
cp existing new
ln existing new
ln -s rel-or-abs-path new

The confusing thing in the ln -s case is that if the path is relative, 
it is
resolved with respect to the directory of new, not the current directory
where the command is executing.

I suspect that this altered semantics of the source argument is actually 
the
root cause of then becoming confused about the order of the arguments.
Since the rel-or-abs-path often isn't a working path from the current
directory to the desired link target, but simply specifies the content
of the link, your brain thinks of the operation as a variable 
assignment:
stuffing the specified link with the given literal value.

I think this is what is fixed by the -r option of the GNU Coreutils ln.
If you use -r, then it's just:

ln -sr orig new   # like plain ln, cp or mv

With -r, if orig is relative, it is understood relative to the current
working directory, not to the link's directory. If the object exists,
then orig is the actual path from here to that object.

The orig and new paths are canonicalized, and then the relative path
R from $(dirname new-canon) to orig-canon is calculated. Then the
link is created as if ln -s R new.

I suspect if you start using "ln -sr original-item link-to-it",
and no longer think of the operation as stuffing a literally specified
piece of content into the variable-like link object, but as creating
a virtual copy of original-item named link-to-it, the recurrent
confusion may be cured.