`command -v` portability

The "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.

this is another fix of #196 (closed)

mentioned in merge request !43 (closed)

added 5 commits

• d11b33ec - 1 commit from branch xdg:master
• fb51a047 - kill off whitespace errors
• 17c7c995 - remove bashisms from POSIX sh script
• d7b10b42 - command_exec: run external command using env instead of which
• 79026aab - Replace all remaining usage of non-portable 'which' with POSIX command -v

Compare with previous version

Apparently so.

But it's not entirely clear what to do or who to ask in order to get anything merged. Hence my MR has been outstanding for a year, and is collecting duplicates.

Oh well, at least the code doesn't change often enough for gitlab's autorebase to be unable to figure out how to rebase. ;)

(Then again that itself might be worrisome.)

It is okay. I just mentioned the relevant issue number for GitLab links.

Your merge request suggests to remove redirection of stderr, 2>&1. Is it safe? POSIX does not forbid printing diagnostic messages of the command utility. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Do we not end up with multiple useless output when trying to open something? Like

command: qwerty: not found

I have checked Bash and Dash, their command prints nothing on such an error.

On the contrary, my reading of POSIX is that it does forbid printing diagnostic messages... when using the -v option.

Otherwise, no output shall be written and the exit status shall reflect that the name was not found.

I'm not aware of a shell that does print diagnostics on the -v option.

The other use of command to run a command, not print the location of the command, does print diagnostics.

BusyBox built-in shell also prints nothing when a command is not found.

BusyBox v1.30.1 (Ubuntu 1:1.30.1-6ubuntu3.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ command -v qwerty
~ $ echo $?
127

Nor do ksh, zsh, mksh...

Busybox sh (actually ash) was created by importing the dash source code into the busybox git tree.

Periodically, the Busybox project imports commits of the form "Upstream commit: ..." in order to re-sync dash changes, though busybox ash has expanded the scope of the original code import (for example, it has a CONFIG_ASH_BASH_COMPAT: "bash-compatible extensions").

So they are likely to behave the same or similar. :)

mentioned in issue #196 (closed)

An alternative would be to use command instead of env, but that would run a special built-in with exit code 0, if such a built-in name was passed as the first argument.

Right. The commit message implies the problem of command though the fact that it's not part of the other changes to use command -v, but it doesn't say so straight out I guess.

It would be lovely to get this in.

mentioned in merge request !60 (closed)

I'd be delighted to get this in, and am more than happy to accommodate any review feedback, of which there has been (to date) exactly zero of.

Really not sure how to help this MR move along. :( But I live in eternal hope, one day...

mentioned in merge request !52 (merged)

This looks great! Alas, I am not an XDG developer.

In case anyone wakes up, could you rebase this MR and kill the remaining uses of which? (There's at least one left in xdg-email.in)

I do not see any such remaining references.

https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/e8d305ce14f33d35f9a4296e191ae57ba20a4796/scripts/xdg-email.in#L101

Aha, that was added in the recently merged commit.

OK I'm woken up, but this needs to be rebased indeed, and the button to do so doesn't work. @eschwartz can you rebase this MR?

It cleanly rebased, but maybe I somehow messed up permissions for maintainers to do so as well? I did think that was supposed to be automatic though.

added 5 commits

• 1a58bc28 - 1 commit from branch xdg:master
• 286c020f - kill off whitespace errors
• 3a942c88 - remove bashisms from POSIX sh script
• abcf02fb - command_exec: run external command using env instead of which
• 826699ad - Replace all remaining usage of non-portable 'which' with POSIX command -v

Compare with previous version

added 4 commits

• 2db83fdc - kill off whitespace errors
• 7f873416 - remove bashisms from POSIX sh script
• cd5c010b - command_exec: run external command using env instead of which
• bd21104b - Replace all remaining usage of non-portable 'which' with POSIX command -v

Compare with previous version

added 5 commits

• 1a58bc28 - 1 commit from branch xdg:master
• 3eaf2f3c - kill off whitespace errors
• 1d580420 - remove bashisms from POSIX sh script
• 80d025ae - command_exec: run external command using env instead of which
• 8ae02631 - Replace all remaining usage of non-portable 'which' with POSIX command -v

Compare with previous version

merged

mentioned in merge request !115 (merged)

mentioned in commit f113a8b9