`command -v` portability
- Nov 06, 2022
-
-
Eli Schwartz authoredThe "which" utility is not guaranteed to be installed, and if it is, its behavior is not portable. Conversely, the "command -v" shell builtin is required to exist in all POSIX 2008 compliant shells, and is thus guaranteed to work everywhere. Examples of open-source shells likely to be installed as /bin/sh on Linux, which implement the 12-year-old standard: ash, bash, busybox, dash, ksh, mksh and zsh. A side benefit of using the POSIX portable option is that it does not require an external disk executable to be forked. This therefore represents a mild speedup.
-
Eli Schwartz authored
Instead of using the 'which' program to resolve a command to an on-disk executable filename, use the 'env' program to run it. The former is non-portable and may not be installed on all systems, while the latter is guaranteed to be anywhere. I believe the intention of this code was to ensure that when running completely arbitrary third-party Exec= specifications, we do not accidentally end up running a conflicting shell function definition. Using 'env' fulfills this goal by entering a new environment context with an unmodified environment (we do not make use of env's stated purpose of creating a modified enviroment context) and then invoking the command using exec(3) rather than a shell.
-
Eli Schwartz authored
The &> redirection operator is a bash-specific shorthand for the POSIX combined redirection operators >/dev/null 2>&1 and must not be used in portable scripts under any circumstances.
-
Eli Schwartz authored
Trailing whitespace makes my .vimrc unhappy, and serves no useful purpose. Remove them now, so they don't intermingle with followup commit changes.
-