Debian's which hunt [LWN.net]

Debian's which hunt

Posted Nov 16, 2021 14:07 UTC (Tue) by nye (guest, #51576)
In reply to: Debian's which hunt by NYKevin
Parent article: Debian's which hunt

> ln(1) wants the target first, against all common sense

$ mv old new
$ cp old new
$ ln old new

These are all the same - why is that against all common sense? Are you saying that you think ln should be changed to work differently from the others, or that they should all have the new file before the source file, like memcpy()?

to post comments

Debian's which hunt

Posted Nov 16, 2021 14:20 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

My issue with it lies more in completion and thought process when writing it than anything else. The `old` argument is relative to the `new` final location. But I must write `old` before I have written where `new` is (or write the command's arguments in reverse order). Of course, if `old` is absolute or `new` lacks a `/`, it all works out just fine, but when it doesn't, I have to stop and remember that tab completion is going to lead me astray with `old`.

Debian's which hunt

Posted Nov 16, 2021 15:50 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Exactly.

My brain thinks that copy, mv, etc all take a "copy" of the first argument, and leave it in the second.

ln is the "wrong" way round, in that it leaves a copy of the second argument in the first.

THAT is why there is no such thing as "intuitive" software - what you think of as bleeding obvious, I think of as "who the hell designed that monstrosity!" (and vice versa, of course :-)

Cheers,
Wol

Debian's which hunt

Posted Nov 16, 2021 16:47 UTC (Tue) by jezuch (subscriber, #52988) [Link]

I still don't get it. You "link" something into some other place. There is now a new file with the same contents as the "old" file. How's that different from copy?

Or is the mental model "create a link <here> to <this file>" instead of "link <this file> <there>"? Perhaps the former makes more sense to native speakers ;)

Debian's which hunt

Posted Nov 16, 2021 16:49 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (1 responses)

If you use `ln --relative --symlink` or `ln -rs` then the symlink target is resolved relative to the current directory (so you can use your tab completion) and the proper relative path is placed in the symlink.

$ mkdir -p a/b/c
$ touch test.file
$ ln -rs test.file a/b/c
$ ls -l a/b/c
total 0
lrwxrwxrwx 1 user group 18 Nov 16 00:00 test.file -> ../../../test.file

The --relative option was introduced in GNU coreutils 8.16.

Debian's which hunt

Posted Nov 16, 2021 21:35 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

That is indeed useful for on the command line. Unfortunately, being GNU-specific, I am stuck without it for portable scripts. And some testing shows that `../` in the presence of directory symlinks shifting around what `../` means doesn't confuse it (probably by doing `realpath` on everything rather than trying to do string logic on paths).