According to the POSIX spec http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html: EXIT STATUS ... 127 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 #!/bin/sh fake-command $ ./run-fake-command.sh ; echo $? ./run-fake-command.sh: fake-command: not found 127 $ fake-command ; echo $? -sh: fake-command: not found 127 $ sh fake-command ; echo $? sh: cannot open fake-command: No such file or directory 2 $ 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: Author: jilles Date: Tue Nov 27 21:50:00 UTC 2018 New revision: 341097 URL: https://svnweb.freebsd.org/changeset/base/341097 Log: 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. PR: 231986 Changes: head/bin/sh/input.c head/bin/sh/sh.1 head/bin/sh/tests/errors/Makefile head/bin/sh/tests/errors/script-error1.0
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.