deprecated `which` prints warnings to stderr

[umlaeute]

[compiler/utils/exepath.cpp] provides a utility to get the full path to a binary: exepath::get().

Internally this uses the which tool to resolve binaries that live in the PATH of the current user.

Starting with Debian/bookworm (currently testing) the which utility is declared deprecated, as it is not standardized and there are various competing and obviously incompatible implementations out there (don't ask me for details; i guess the simple use of which <somebinary> is portable enough). (I don't know whether other distributions will follow this deprecation; most likely, downstream distros (like Ubuntu) will just inherit it.)

In any case, it is suggested to use the POSIX conformant (and thus standardized) command -v instead. This is done rather verbosely through stderr, whenever which is invoked:

$ which faust
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/usr/bin/faust
$ which faust >/dev/null
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.

Since faust internally invokes the which command, this leads to a printout on stderr for each and every invocation of faust:

$ faust lowCut.dsp -o lowCut.cpp
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.

i find this rather annoying. it is especially harmful when running testsuites where you really don't want any noise on the stderr.

[sletz]

Do you have a patch to fix this?

[umlaeute]

here's a few suggestions to mitigate the problem.

probably it's best to implement more than just one

command -v

Simply replace the invocation of which with an invocation of command -v. Note that command -v is a SHELL BUILTIN, whereas which is an external program. I have done a quick test trying to run a program that popen()s command -v and it seems to work both when being called from the terminal and directly from my desktop (Alt+F2). I guess it is safe to assume that it just works (given that popen() invokes a shell) as long as the shell is POSIX compliant.

I have not tested on other platforms

use system-specific code to find the applications own full path

afaict, exepath::get() is really only used to get the full path of the faust executable itself, so it can properly setup all its search paths. there are other ways to do that, although it seems there is no cross-platform way. https://stackoverflow.com/a/1024937/1169096 lists a few, among them:

• Mac OS X: _NSGetExecutablePath() (man 3 dyld)
• Linux: readlink /proc/self/exe
• Windows: GetModuleFileName() with hModule = NULL

there probably is a reason why the stackoverflow post does not suggest any which trickery as employed in faust :-) so i guess these could at least be preferred over the current implementation (if you want to leave that as a fallback)

suppress printout of stderr

regardless of whether which is the correct tool or not, i think it is a problem that its stderr is output when invoking faust. so i think that should be redirected to /dev/null