On 02/06/2018 05:58 AM, Emilio Pozuelo Monfort wrote: > There are some differences in command vs which, e.g.: > > emilio@tatooine:~$ which ls > /bin/ls > emilio@tatooine:~$ command -v ls > alias ls='ls --color=auto' > > Some special casing would need to be added to handle aliases, whereas with > 'which' we don't. > > OTOH portability is a good goal and I'm happy that you're using xvfb-run, so > if > we can come up with a good and clean solution then that'd be good.
Well, this was a rather interesting summary of options (including why the which command itself might not be what you think it is): https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then I'm not sure I understand the case for avoiding command -v, as it will only fail if the user has somehow set an alias inside a non-interactive script, which implies either modifying the script, or *sourcing* it from an interactive shell. But, there are other options. If the script was strictly bash-only, you could use type -P. From testing bash, dash, and busybox ash, in all cases `hash $command` exited with no output and a successful status, if it detected a command executable in $PATH (bash went so far as to check if the command has executable permissions, which is also what GNU which does), OR it exited with a "permission denied" or "not found" on stderr and a return code of 1. hash is also POSIX. Since xvfb-run is not trying to remember the location of the command, only check that one exists on disk (i.e. `alias xauth=asdafsjdlfkjlsdkfjslfs` would currently break everything if someone was indeed mad enough to use aliases, and also *wanted* to break things), this seems like a reasonable solution as well. -- Eli Schwartz Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
