[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature request: better intuitive syntax LINK=TARGET
From: |
Bernhard Voelker |
Subject: |
Re: feature request: better intuitive syntax LINK=TARGET |
Date: |
Mon, 29 Jun 2020 20:23:03 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 |
On 2020-06-25 17:46, Kaz Kylheku (Coreutils) wrote:
> 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 believe the confusion stems from the terms SOURCE and DESTINATION
which I think has been used in some implementations.
For mv(1) and cp(1) this makes sense, but for ln(1) this wording
messes up the whole thing: of course the 2nd argument is the DESTINATION,
i.e., the place for the newly created link. but when thinking about
links (esp. symlinks), ... well.
If the file-to-link-to is in another directory, and the symlink name should
be identical to the symlink target, then I often use the form without a second
argument:
ln [OPTION]... TARGET
e.g.
$ ln -sv ../somefile
'./somefile' -> '../somefile'
Otherwise, I mostly use the options to ensure that an already existing file
(e.g.
old symlink) gets removed (-f). Also the -n option avoids surprises for me, as
this
also ensures that a symlink to a directory gets replaced (in combination with
-f):
$ ln -nsvf ../some-file-or-dir link-to-file-or-dir
Have a nice day,
Berny