Handling posix_spawn for non-existent binaries

[Paul Smith]

So over the weekend I started some testing on different systems just to
get a feel for where the code is, portability-wise.

I discovered that the enhancement to use posix_spawn instead of
fork/exec results in a number of failed regression tests on older
systems.

The problem doesn't appear on systems with newer glibc versions which
is why I didn't notice it on my development GNU/Linux system.

However on GNU/Linux with oldeer glibc, and also on MacOS, regression
tests are failing because when we run posix_spawn() to start an
executable which doesn't exist we get no error return as we do with
exec.

For vfork/exec if we use the fast path to start a program that doesn't
exist we get this result:

  $ echo 'all:;./foobarbaz' | make -f-
  ./foobarbaz
  make: ./foobarbaz: No such file or directory
  make: *** [/tmp/GmBtW6cg:1: all] Error 127

But for older glibc and for MacOS, we get this result:

  ./foobarbaz
  make: *** [/tmp/GmHL4Q0x:1: all] Error 127

Note there is no error here.

This is not good both because it is very confusing and because it means
regression tests fail, but it seems the result of a known and accepted
deficiency of posix_spawn, as you can read about  here:

http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

(the "Asynchronous Error Notification" section near the end).

The only idea I have so far is to try to detect when this situation
occurs (by looking for the 127 exit status) then using stat() to check
to see if the binary exists (I suppose I need to check for executable
status) and generating the error on my own.

I may need to check the PATH as well since we really invoke
posix_spawnp().

Ugh.