Hrm. The idea that it's written to stderr makes sense though, as the parent process would be listening on that pipe. Whether the exec call itself fails, or the process immediately exits with some other error; the process to determine the error would be the same: i.e. to read the stderr pipe.

What's the benefit of splitting this off to it's own pipe with distinct error handling?

Actually, never mind, I can see why this'd be useful. Would eliminate an easy class of errors a lot more effectively; and would harmonize with windows behaviour. OK. Will review tomorrow.

Hrm. The idea that it's written to stderr makes sense though, as the parent process would be listening on that pipe. Whether the exec call itself fails, or the process immediately exits with some other error; the process to determine the error would be the same: i.e. to read the stderr pipe.

What's the benefit of splitting this off to it's own pipe with distinct error handling?

There are a few issues:

1. this behavior was not made clear in docs since it was introduced, so I assume it's a bug
2. it requires a read right after process start, so its a little bit less intuitive since exec errors almost always seems instantaneous
3. any process could just as easily return -1 as exit code and users can't differentiate it.
4. its not the same on Windows

1. this behavior was not made clear in docs since it was introduced, so I assume it's a bug
2. it requires a read right after process start, so its a little bit less intuitive since exec errors almost always seems instantaneous
3. any process could just as easily return -1 as exit code and users can't differentiate it.
4. its not the same on Windows

Yes, this parallels my understanding. Reviewing now.

Tested this; worked perfectly. Merging.