According to the POSIX spec http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html:
A specified command_file could not be found by a non-interactive shell.
However, sh(1) on FreeBSD 11.2-RELEASE-p4 sometimes returns 2. Consider:
$ cat run-fake-command.sh
$ ./run-fake-command.sh ; echo $?
./run-fake-command.sh: fake-command: not found
$ fake-command ; echo $?
-sh: fake-command: not found
$ sh fake-command ; echo $?
sh: cannot open fake-command: No such file or directory
I think the final "2" should be "127" since it's a non-interactive shell.
Your analysis seems correct, except that "./run-fake-command.sh" and "fake-command" in your example are not governed by the standards text you pasted.
The code 126 near that is for the case where opening the command_file fails for a different reason than that it is not found.
A commit references this bug:
Date: Tue Nov 27 21:50:00 UTC 2018
New revision: 341097
sh: Use 126 and 127 exit status for failures opening a script
This affects scripts named on the command line, named with a '.' special
builtin and found via the PATH %func autoloading mechanism.
Thanks for the fix!
Yes, I agree that not all of my examples are governed by the standards text. I included them in case it helped to identify the fix. (Given the svn diff, I doubt they were useful, but oh well.)
Fixed, no MFC planned.