On 21/06/2019 19:45, Eli Schwartz via arch-general wrote: > On 6/21/19 12:13 PM, Jude DaShiell wrote: >> Also, man which >> If you get a chance the linux cookbook will be informative reading given >> your new position. > Please do *not* use /usr/bin/which, especially not if you write scripts. > It is non-POSIX, not portable between different different systems if you > write scripts, and even on an interactive console where you know you > personally have the "which" package installed, the results are more > confusing and less useful than using the native shell introspection. > > use `command -v` to find where a command exists, or, in bash, `type -a` > if you want to see all possible options. > > For more details, see: > https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 > Especially note the "Status today" paragraphs, and if you stubbornly > wish to continue using "which" despite its well-known pitfalls, then > carefully avoid any systems where "which" is implemented as a csh script > (like many commercial Unix systems today). > > ... > > Use the "conflict" command if you're afraid you may have multiple > versions of an externally available executable file in your $PATH and > you want to check where they are and what you're actually using. > > Since the common use case of "which" is when you actually want to know > whether you're using the wrong version of something, the ideal > interactive debugging tool is "type -a"... but the "conflict" command > can do one better -- limited to executables and not shell builtins, > aliases, or functions -- and list *all* conflicting command binaries. > Should you always create POSIX-compatible scripts though? All these non-POSIX tools were created to ease your job, and you blow them away as non-POSIX? If you're creating a single-purpose local script, I think it's fair to make it a bash script and use tools which you have available on your install, instead of limiting yourself to frankly ridiculous workarounds to the shortcomings of POSIX. Just because a tool can do anything doesn't mean it can do everything well, or that you have enough cognitive capacity at 3 am to write your stupid POSIX-compatible shell scripts. P.S. which is an absolutely terrible command though, modern POSIX alternatives are much better for this specific use case. -- Regards, Juha Kankare