I suppose it could do that, but the implementation is a bit difficult. The only way I can think of to do it reliably is to have the parent open a pipe to the child so that the child can communicate back the errno from the failed exec.

And I would need to go over every possible value of errno and decide which ones warranted an early exit and which ones didn't. It seems like a complicated issue.

Anyway, it's definitely a feature I haven't needed yet. A few years back I did a review of a couple of dozen programs I'd written and put in my ~/bin directory, and the overwhelming majority of them were over-featurized, not under-featurized. I learned that I had wasted a lot of work on features I didn't need. So these days I try to leave out as many features as possible until I'm sure I need them.

The original version of this program left -v unimplemented, but I kept wishing for it, so eventually I put it in. The original version of this program left -r unimplemented, but I haven't yet wished for it, so I haven't put it in yet. Win!

It occurs to me now that if I did decide that I wanted the -r option, the right way to get it would be to write a separate shuffle utility that shuffles its arguments and prints them in random order. Then instead of runN -r ... I could runN `shuffle ...`. Win!

Similarly, it has occurred to me more than once that the program completely fails to report the exit status of the subprocesses. Your suggestion is part of that. But I haven't needed to find out the exit status of the subprocesses, so I haven't tried to fix that.