Red Hat Bugzilla – Bug 981443
wait vs. invalid pid/job spec: man page update OR wait builtin fix might be needed
Last modified: 2017-02-28 04:34:17 EST
Just noticed this discrepancy man page vs. reality:
> SHELL BUILTIN COMMANDS
> wait [n ...]
> [...] the return status is zero. [...] the return status is 127.
> Otherwise, the return status is the exit status of the last
> process or job waited for.
> EXIT STATUS
> All builtins return an exit status of 2 to indicate incorrect usage.
$ wait foo; echo $?
> -bash: wait: `foo': not a pid or valid job spec
As per man page, I would expect the above command to be instance
of incorrect usage (as no additional possibility is enumerated
at the wait description), hence would expect 2 to be the exit status.
Apparently, there is an inherent danger of exit status aliasing when
the last process or job waited for exits with 1 (or 2).
Using 2 instead of 1 would IMHO be (to limited extent) safer in this
regard, as quite common C-based program's logic is to use just
0 (EXIT_SUCCESS) and 1 (EXIT_FAILURE).
Looks like all (or majority) builtins return 1 on error. Easier is to change man page. Will ask upstream.
I presume this can be closed with manpage update from comment 7. Is it ok with you ?
Well, the expected outcome really is that wait builtin in bash won't
return 1 because of the common failure exit code aliasing issue
described in [comment 0].
my intepretation is that it would be entirely OK if it returned 127
in case of nonsensical PID operand.
The referred man page update is no remedy here, I am afraid.
Moving this bug to rawhide for further discussion.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.