Re: style, sysexits(3), and man RETURN VALUES for sys programs

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 3 Jun 2023 13:45:44 +0200
    From:        tlaronde%polynum.com@localhost
    Message-ID:  <ZHsn6PJtAkGjE1NY%polynum.com@localhost>

  | Rhialto pointed me to sysexits(3) that was exactly what I was looking
  | for (for inetd(8) revision). So kudos to him!

I deliberately didn't mention sysexits.h (or sysexits(3)) as I don't
think it is really appropriate here.

sysexits works when the calling program (one which execs & then waits for
the one which is to use those exit values) understands the convention, and
can take action based upon the different exit codes.

That is not the case for inetd - unless you're planning on creating another
tool to run inetd (inetdd ?) which would start it and wait for exits from it,
and decide what to do next based upon why inetd exited.

sysexits was created with sendmail (or perhaps delivermail which preceded it)
as a way to allow programs which send mail to know what happened when they
transmit a message by an fork & exec of sendmail (these days most submission
is done via SMTP, or the submission protocol variant of that, and those exit
codes aren't really needed there any more).

Without that, all the calling program sees is "program exited with status 78"
so something went wrong, but what?  Having to go back to the manual (or
system include file, which would be worse) to find out what that error number
means, is horrid - that's the way systems used to work in the dark ages,
when actually putting error messages, as strings, in programs was too
costly - and believe me, you don't want to be in that environment.

If there's also a message that explains the error, then you don't need much
in the way of specifics in the exit status, as all anyone will look at is the
error message - and the most you want (possibly) to convey in the exit status
is whether the reason for exiting is one that can be easily fixed, or one which
will require real attention, and most programs don't even need that, just
"all ok" or "failed" is all that is needed in the exit status.

If there's no message (which includes syslog) then why isn't there?   There
are odd applications which really want to be silent, but I don't think inetd
is one of those.

Unless there is a really good reason - which would amount to there actually
being something which will interpret the exit status from inetd for more that
ok/not ok then I wouldn't be going near sysexits.

kre