Debian's which hunt [LWN.net]

Debian's which hunt

Posted Oct 28, 2021 16:12 UTC (Thu) by jhoblitt (subscriber, #77733)
Parent article: Debian's which hunt

While I confess to frequently using `which` on the interactive command line, this utility has been causing me grief in build systems for decades. The only sane thing to do when relying on a shell is to replace it with `command -v`. The behavior of `which` is *non-standard*. It is not present by default in many operating systems, including many flavors of linux. The behavior of the command, if it exists, can be strangely different. This isn't theoretical, it has caused real world portability I've experienced. Sadly, the Huffman encoding and memorability of `command -v` is terrible but it has been part of posix essentially "forever".

to post comments

Debian's which hunt

Posted Oct 28, 2021 17:05 UTC (Thu) by ballombe (subscriber, #9523) [Link] (21 responses)

At the same time a number of shells did not implemented it correctly for a long time, this was the original motivation for which.

Debian's which hunt

Posted Oct 28, 2021 17:12 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

Everything is awful...

Debian's which hunt

Posted Oct 28, 2021 18:14 UTC (Thu) by Taywee (guest, #154131) [Link]

Notably, Debian's dash shell has some issues with command -v: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264

Debian's which hunt

Posted Oct 28, 2021 20:27 UTC (Thu) by Deleted user 129183 (guest, #129183) [Link] (18 responses)

> At the same time a number of shells did not implemented it correctly for a long time, this was the original motivation for which.

The original motivation for ‘which’ was the original C shell not having any equivalent built-in functionality, so somebody hacked together a C shell script that not only found a relevant program in the search path, but also checked if a command was aliased to anything, since C shell had an unfortunate misfeature of executing its initialization files even when you ran such script non-interactively. Seriously, look at this:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/whi...

When people switched to other, better shells, they kept using ‘which’ and even worse – passed this “knowledge” to other, younger users who promptly started using ‘which’ themselves, and at this point a major feature of it was lost, since the script didn’t care about any aliases defined in any shell other than the C shell. And since people mostly learn *n?x based on a hearsay, not reading the documentation*, usage of ‘which’ persists to this day and people don’t learn about better alternatives.

* Cannot blame them, honestly. When MS-DOS 6.0, released in 1993 had nice, interactive and hyperlinked help system that allowed me to learn DOS to an advanced degree in a year back when I was only a small child, Linux and BSDs have still mostly only inconvenient, horrible to use man pages which were designed originally to be printed physically as a book, but are terribly inadequate for an interactive on-screen usage. Sure, there is also GNU Texinfo, but most people don’t know about it – because “all documentation is in the man pages” is another incorrect knowledge passed down by generations – and its default command line viewer has an outdated, unergonomical, contrary to people’s expectations user interface.

‘Which’ is not the only C-shellism that managed to unfortunately persist to this day. Every time you see people recommending other people to learn some magic incantation like ‘sudo !@#$%^&’, you see another case of it. Back when C shell was in the widespread use, no shell actually implemented interactive command line editing or interactive history recall and search, so this was the only option to reexecute a previous command with some modification, and in fact a major selling point of the C shell. Today, it’s basically pointless, requiring bigger cognitive load, more prone to mistakes (especially those of the catastrophic kind), and in most typical cases, doesn’t even save any keystroke – for example, S U D O SPACE ! ! ENTER has the same amount of them as ↑ HOME S U D O SPACE ENTER. But the second one is much more intuitive.

Debian's which hunt

Posted Oct 29, 2021 12:01 UTC (Fri) by epa (subscriber, #39769) [Link] (6 responses)

I've always found GNU info to be painful to use, navigating around a couple of paragraphs at a time with weird keystrokes for 'next section' and 'up one level'. And this from someone who spends all day in Emacs. Yep, you said the same, so we agree there.

A manual page has a much simpler user interface. You just read it and scroll up and down. A workaround is to pipe info into less so it splurges all the content.

Debian's which hunt

Posted Oct 29, 2021 12:47 UTC (Fri) by nix (subscriber, #2304) [Link]

Info has a better UI of late (a very low bar): it actually handles cursor keys, page up and page down like every other program on Earth written in the last forty years does.

I don't find u (up), n (next node) and l (go back) to be too confusing. Its other keybindings are... harder to remember.

(And in thirty years of using it I never realised that you could pipe it into other programs to get whole info documents at once.)

Debian's which hunt

Posted Oct 29, 2021 13:44 UTC (Fri) by mti (subscriber, #5390) [Link] (4 responses)

I have started to use 'pinfo' to read info pages. Nice colors and more intuitive key bindings.

Debian's which hunt

Posted Oct 29, 2021 20:43 UTC (Fri) by Deleted user 129183 (guest, #129183) [Link] (3 responses)

> I have started to use 'pinfo' to read info pages.

Pinfo is good, but unfortunately the only distribution that I know of that installs it by default and actually aliases ‘info’ command to it is GoboLinux. Apparently filesystem isn’t the only thing that it does better than the usual GNU/Linux distributions. And those other distributions like to install by default lots of stuff that most people aren’t even gonna use once, like Vim, ‘rmt’ or ‘mailx’, so i guess Pinfo wouldn’t bloat them too much – though one can argue that it would also belong in _that_ category…

Debian's which hunt

Posted Oct 29, 2021 20:57 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

If you want a distro that doesn't bloat your system, what about gentoo :-)

Okay, admin'ing your own system will get a bit harder, but you'll KNOW what's there and what it's doing, because you put it there and you told it what to do.

Cheers,
Wol

Debian's which hunt

Posted Oct 30, 2021 14:29 UTC (Sat) by Deleted user 129183 (guest, #129183) [Link]

> If you want a distro that doesn't bloat your system, what about gentoo :-)

Sure, there’s also Arch that doesn’t even include ‘man’ command in its base system.

But I don’t really care about bloat, if I did, I surely wouldn’t argue that Pinfo should be installed by default. I just think that the choice of default packages should be based on practical, rather than historical considerations.

Debian's which hunt

Posted Nov 2, 2021 8:06 UTC (Tue) by flussence (guest, #85566) [Link]

The compiling-time argument may have become less important over the years, but you still have to lug around build dependencies for everything. When CUPS unexpectedly appears in the installation list, for instance, it's usually a sign that something's trying to smuggle yet another bundled copy of chromium onto your system. Or Java.

Debian's which hunt

Posted Oct 29, 2021 13:47 UTC (Fri) by rsidd (subscriber, #2582) [Link] (1 responses)

This is the sort of interesting historical comment for witch I read LWN, thank you.

Debian's which hunt

Posted Oct 29, 2021 14:59 UTC (Fri) by smoogen (subscriber, #97) [Link]

Agreed. I dimmly remembered my instructor in the late 1980's telling me about the differences (and hidden horrors) between csh and sh so that we could write scripts on our SunOS systems witch would also work on our new HP-UX box. Reading this sparked a bunch of 'ooooh yeah.' and why we quickly moved all our systems to use tcsh to get edited history.

** ps thanks for the hidden pun.

Debian's which hunt

Posted Oct 31, 2021 17:52 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

"sudo !!" has less interactive editing and is faster for me (arrow-up is not just a key-press, it is an interaction, so is Home, to a lesser extent). I often use somewhat slow connections and this is meaningful for me.

Debian's which hunt

Posted Nov 1, 2021 15:38 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (6 responses)

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 (guest, #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).

Debian's which hunt

Posted Nov 4, 2021 13:59 UTC (Thu) by jschrod (subscriber, #1646) [Link]

While I don't use !!, !^ and !$ are used by me all the time; and are not so easy replaced by interactive editing with cursor keys. Even !* is sometimes easier to add to a longer new command then editing the previous command. And, if we talk about readline, don't forget M-C-e to expand such edit escapes, to be able to change them afterwards.

So you have chosen exactly an ! edit escape that one needs very seldomly and ignored the ones that are still usable nowadays. Not a very fair description, IMNSHO.