Debian's which hunt [LWN.net]

Debian's which hunt

Posted Oct 28, 2021 19:01 UTC (Thu) by marcH (subscriber, #57642)
In reply to: Debian's which hunt by abatters
Parent article: Debian's which hunt

My favorite demo

$ which type
/usr/bin/type
$ type type
type is a shell builtin

I stopped using "which" after that and switched to type -p

BTW https://github.com/koalaman/shellcheck/wiki/SC2230

(everyone should use shellcheck)

to post comments

Debian's which hunt

Posted Oct 29, 2021 6:24 UTC (Fri) by weberm (guest, #131630) [Link] (4 responses)

Pretty useless, isn't it?

$ which type
$ type type
type is a shell builtin
$ type -p type
$
# yes, its exit status tells me type exists, but not where
$ type ls
ls is aliased to `ls --color=auto'
# I hate that alias with a passion but sometimes forget to remove it. Not the point. It ought to tell me where the expanded alias is pulling that 'ls' in.
$ which ls
/bin/ls
$ command -v ls
alias ls='ls --color=auto'
$ command -V ls
ls is aliased to `ls --color=auto'

Nothing scratches my back just like which does.

Debian's which hunt

Posted Oct 29, 2021 13:59 UTC (Fri) by pj (subscriber, #4506) [Link] (2 responses)

$ type -a ls
ls is aliased to `ls -F --color=auto'
ls is /bin/ls

IMO, `type` seems to be the best-thought-out version of this tool, and should be made standard.

Debian's which hunt

Posted Oct 29, 2021 21:15 UTC (Fri) by weberm (guest, #131630) [Link] (1 responses)

I assume you're using bash? zsh?

$ type -a ls
mksh: whence: -a: unknown option

IMO which being an external tool actually comes in quite handy here. It has its drawbacks, but also its benefits.

Debian's which hunt

Posted Oct 29, 2021 21:29 UTC (Fri) by marcH (subscriber, #57642) [Link]

For scripts it may depend on what you're trying to achieve but in _interactive_ use you should always, always use the builtin provided by your particular shell. It's likely not portable but who cares: it's interactive use. There's no drawback and huge benefits.

Debian's which hunt

Posted Oct 29, 2021 16:28 UTC (Fri) by overfl0w (guest, #155055) [Link]

On the other hand on my system I have vim and nvim installed simultaneously. I also apparently have the following alias which I've forgotten about in .bashrc:
alias vim='nvim' in .bashrc

So when I execute the 'vim' command, actually 'nvim' is executed.

$ which vim
/usr/bin/vim
$ command -v vim
alias vim='nvim'

So in this particular case 'which' did not return the correct path. Perhaps this is due to the fact that 'vim' is a valid command. But if I executed 'vim', it would not execute the executable returned by 'which'. I found this by accident as I hadn't heard about 'command -v' before.

Debian's which hunt

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

So /usr/bin/type is a shell script which just does:

#!/usr/bin/sh
builtin type "$@"

It is there so you can run type foo in CSH or some other shell and still have it work. So which is telling you what could be executed via your path no matter what your shell is.

Debian's which hunt

Posted Oct 29, 2021 15:26 UTC (Fri) by marcH (subscriber, #57642) [Link] (2 responses)

> So which is telling you what could be executed via your path no matter what your shell is.

Ignoring functions , built-in and aliases is really harmful. This has cost me a lot of time so I simply stopped using it. Problem solved.

Debian's which hunt

Posted Oct 29, 2021 15:52 UTC (Fri) by marcH (subscriber, #57642) [Link]

To be clear:

- You should use "which" if you're still stuck with a C-shell for some reason
$ tcsh
> which which
which: shell built-in command.

More C-shell history below

- I'm not saying "which" must be removed or deprecated or whatever (I don't care). But I am saying it is harmful for bash and other Bourne shell users and that they should stop using it for their own good.

Debian's which hunt

Posted Oct 29, 2021 21:38 UTC (Fri) by buck (subscriber, #55985) [Link]

well, /usr/bin/which can't (easily) tell you if something is an alias or shell function, since it's not running in your shell. but the C/tcsh shell builtin `which` or Bourne/Korn/bash builtin `type` can. (sorry to possibly exclude mention of your shell; i just don't have any experience with it)

and, yes, count me in as one of the folks who never knew about the existence of `command` and had always resorted to `type -p` (and will continue to use it for my [occasional] purposes, which is in scripts and not interactive shells, when having `command -v` tell me about an alias isn't gonna work)

as for the matter somebody else raised about fetishizing POSIX, one only has to look at a `configure` script (maybe more so in the past than nowadays, as i guess checks for things like ULTRIX quirks may have gone by the wayside) to find plenty of reasons to be thankful for when an OS or distribution tries to take its cue from a formal or de-facto or what's-everybody-else-doing standard to reduce the heterogeneity when it doesn't add any meaningful value, ... if it's not already too well entrenched. and Linux itself got to be the dominant force it is by using (might-as-well-be) POSIX conformance as the calling card to present to get the door open, for it then to barge in and trample all the other guests

Debian's which hunt

Posted Nov 12, 2021 18:44 UTC (Fri) by rmc032 (guest, #131846) [Link]

> I stopped using "which" after that and switched to type -p

Which ironically, `type -p` is a GNU specific option and isn't POSIX compliant, as far as I can tell. I think I have the correct version here, but skimming the POSIX shell standard, it seems that the specification for the `type` utility doesn't list any options:
- OpenGroup link: https://pubs.opengroup.org/onlinepubs/9699919799/utilitie...
- Linux POSIX man page link: https://man7.org/linux/man-pages/man1/type.1p.html

Figured it was worth mentioning since a decent chunk of the article discussion is about how `command -v` is the POSIX way to find a command rather than `which`