Follow-on audit after r13008. The flexml failure was one instance of a general
habit: asking the shell whether a command exists in a way that is not portable.
"which" is an external program, not a shell builtin, and Debian dropped it from
debianutils in 13 - so on the newest Debian and Ubuntu it may simply not be
installed. Every `which foo` then produces nothing, and the surrounding code
concludes the tool is absent (or, where the result is used as a path, gets an
empty one). That is the same shape of bug as r13008, just failing the other way
round: there, a missing tool looked present; here, a present tool looks missing.
Converted to "command -v", which is POSIX, is built into every shell, and
prints a path on stdout only when the command exists:
- bin/aubit: 26 call sites - the compiler wrapper's probes for gcc, make,
ldconfig, locate, xdg-open, xmessage, desktop-file-install, 4glc, 4glpc and
the rest. This is the script CLAUDE.md tells everyone to invoke, so it is the
one that matters most.
- Makefile: the check.exe.in.path target, which exists to refuse to install
when Aubit executables are still on PATH. With "which" gone that check
silently passes, which is exactly backwards for a safety check.
- bin/aubitbuild.sh.in: was deriving a script's path by picking field 3 or 4
out of "type" output, with a fallback because the field moves depending on
whether the command is hashed - and the wording differs between shells
anyway. command -v gives the path directly. Patched in the .in template, as
configure generates bin/aubitbuild.sh from it.
Two things found in passing and deliberately left alone, both worth a look:
- bin/aubit line 806 reads x="`command -v $prg >/dev/null 2>&1`" - stdout goes
to /dev/null, so x is always empty and the "Found in PATH" branch below it
has never run. Removing the redirect would switch on a branch that does
rm -rf on what it finds, under A4GL_FORCE_CLEAN, so that is a decision to
make deliberately rather than as part of a mechanical sweep.
- bin/aubit has no shebang: the "#!/bin/sh" in it is on line 32, not line 1.
It also does not parse under dash (bash-isms), so it relies on being started
by a bash-compatible shell. It works today because whatever runs it is bash;
it would break where /bin/sh is dash and something execs it directly.
The one remaining "type" probe is PKG_CONFIG_ROOT_CYGPATH in
incl/Makefile-install.mki, which parses type's output for a Cygwin path.
Cygwin is no longer a supported platform, so it is left as it is.
