[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ralph Corderoy
Subject: [Nmh-workers] exit(3) Value of nmh Commands.
Date: Sun, 27 Aug 2017 15:24:21 +0100


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 $?

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.

        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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]