[Nmh-workers] exit(3) Value of nmh Commands.

[Ralph Corderoy]

Hi,

exit(3) values are zero for success, non-zero for failure.  The value is
eight bits wide but shells map signals onto [0x80, 0xff] so exit(128 +
14) would be ambiguous to the parent.

    $ sh -c 'kill -14 $$'
    Alarm clock
    $ echo $? $(($? - 0x80))
    142 14

Shells also nab the top few of [0, 0x7f] for their own use.

    $ foobar
    -bash: foobar: command not found
    $ echo $?
    127

So that leaves [0, 120], say, for passing to exit(3).

Conventionally, 0 is success, 1 is failure, and perhaps 2, 3... are used
to indicate particular kinds of failure, e.g. grep(1) uses [0, 2].

mhparam(1) deviates.

    EXIT STATUS
        mhparam returns the number of components that were not found,
        but limits the return value to 120 to avoid ambiguity, e.g. 127
        is used by shells to indicate ‘command not found', and 256 would
        wrap to 0, falsely indicating success.

(I added the 120 limit in e8eb3afb.)

I'd like to switch mhparam to the normal 0 or 1 that Unix commands
generally follow.  After all, rm(1) doesn't attempt to return a tally of
files it couldn't remove.  Does this need advance notice in 1.8's NEWS
so it can only happen in 1.9.  IOW, is anyone likely to be depending on
this?

The same goes for nmh commands generally;  I think we should move
towards small integer exit values for distinct meanings.  Seven bits is
just too narrow a channel to try and bother expressing a count, and it
adds documentation overhead.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy