The call to which in new_checkexec prints to stderr if the executable isn't in the path. For instance, running abcde, I see: which: no icedax in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/usr/games/bin:/var/lib/bin) The stderr of which should be suppressed.
Hmmm, I don't see that at all here. What system are you running on, please?
I run on gentoo, so it's not the most reproducible environment. however, it should be easy to repro the issue. I encountered it when trying to rip a CD that was not in CDDB and I did not icedax installed. When CDDB failed, it fell back to calling do_cdtext. in do_cdtext, the first line checks for an installed executable of icedax ("if new_checkexec icedax; then") and the contents of new_checkexec uses "which" to determine if the binary is executable in path. When the call to which fails, it prints an error like that in the initial comment to be printed to stderr. you should be able to just hack in an early call of new_checkexec foobarbaz to see it fail the which and its output. The which statement in new_checkexec probably should just have stderr /dev/null'ed.
I can see what it's doing with "which" here, but if I run which on a non-existent program here I don't get any errors: tack:~$ which fdsakfkjshj tack:~$ which fdsakfkjshj ; echo $? 1 tack:~$ which bash ; echo $? /bin/bash 0 That's what's confusing me. On my Debian system "which" is a separate program from the "debianutils" package. Where does yours come from? :-)
ah ok. My which is installed through gentoo's portage from https://carlowood.github.io/which/ version 2.21. I confirmed with a coworker on OSX that which installed through brew (also v2.21) also prints an error message on stderr but the native OSX which exits silently.
Thanks for the info. I've just commited a fix for this, throwing stderr to /dev/null wherever we use "which".