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
