Debian's which hunt
Debian's which hunt
Posted Oct 28, 2021 20:27 UTC (Thu) by Deleted user 129183 (guest, #129183)In reply to: Debian's which hunt by ballombe
Parent article: Debian's which hunt
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.
Posted Oct 29, 2021 12:01 UTC (Fri)
by epa (subscriber, #39769)
[Link] (6 responses)
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.
Posted Oct 29, 2021 12:47 UTC (Fri)
by nix (subscriber, #2304)
[Link]
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.)
Posted Oct 29, 2021 13:44 UTC (Fri)
by mti (subscriber, #5390)
[Link] (4 responses)
Posted Oct 29, 2021 20:43 UTC (Fri)
by Deleted user 129183 (guest, #129183)
[Link] (3 responses)
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…
Posted Oct 29, 2021 20:57 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Oct 30, 2021 14:29 UTC (Sat)
by Deleted user 129183 (guest, #129183)
[Link]
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.
Posted Nov 2, 2021 8:06 UTC (Tue)
by flussence (guest, #85566)
[Link]
Posted Oct 29, 2021 13:47 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Oct 29, 2021 14:59 UTC (Fri)
by smoogen (subscriber, #97)
[Link]
** ps thanks for the hidden pun.
Posted Oct 31, 2021 17:52 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link]
Posted Nov 1, 2021 15:38 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Posted Nov 16, 2021 14:07 UTC (Tue)
by nye (subscriber, #51576)
[Link] (5 responses)
$ mv 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()?
Posted Nov 16, 2021 14:20 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Nov 16, 2021 15:50 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Nov 16, 2021 16:47 UTC (Tue)
by jezuch (subscriber, #52988)
[Link]
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 ;)
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. The --relative option was introduced in GNU coreutils 8.16.
Posted Nov 16, 2021 21:35 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 4, 2021 13:59 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
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.
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
Wol
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
Debian's which hunt
$ cp old new
$ ln old new
Debian's which hunt
Debian's which hunt
Wol
Debian's which hunt
Debian's which hunt
$ 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
Debian's which hunt
Debian's which hunt