Debian's which hunt

Posted Nov 1, 2021 15:38 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: Debian's which hunt by Deleted user 129183
Parent article: Debian's which hunt

IMHO short man pages are fine for interactive use (e.g. reminding myself that ln(1) wants the target first, against all common sense). It's only when you try to read something ungodly long like bash(1) or complicated like sudoers(5) that it gets to be bad. But nowadays the web has completely replaced that use case anyway (especially since the GNU people started compiling their texinfo pages into HTML and putting them online).

Debian's which hunt

Posted Nov 16, 2021 14:07 UTC (Tue) by nye (subscriber, #51576) [Link] (5 responses)

> 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()?

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).