tech-userlevel archive

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

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

In article <>,  <> wrote:
>Le Sat, Jul 01, 2023 at 06:39:32PM -0000, Christos Zoulas a écrit :
>> In article <>,
>> Taylor R Campbell  <> wrote:
>> >> Date: Sat, 3 Jun 2023 13:45:44 +0200
>> >> From:
>> >> 
>> >> So I suggest to add a mention of sysexits(7) to style.
>> >
>> >I don't think sysexits(7) is consistently used enough, or really
>> >useful enough, to warrant being a part of the style guide.  Very few
>> >programs, even those in src, use it, and I don't think anything
>> >_relies_ on it for semantics in calling programs.
>> I agree; nothing really uses sysexits except inside sendmail perhaps...
>> It has been around for more than 40 years:
>> ^As 00062/00000/00000
>> ^Ad D 1.1 81/10/15 20:29:54 eric 1 0 
>> ^Ac date and time created 81/10/15 20:29:54 by eric
>> and one would think that if it was useful, it would have caught on by now.
>Since you don't discuss anything particular to sysexits, your sentence
>is then a broad, general judgement. So let's see:
>"NetBSD 1996 -- 2023
>It has been around for 28 years. And one would think that if it was
>useful, it would have caught on by now."

It keeps changing and improving. Many pieces of the system are used elsewhere.

>If the former is true, the latter is true. Is this latter true?
>As far as I'm concerned, even if the latter is true, in numbers, it has
>no bearing on the usefulness of NetBSD. Only on the stupidity of the

Yes, it is numbers that make it less than useful. Shells don't even print
exit values by default.

>And since you mention init(8), the funny thing is that we are discussing
>about a server that, generally, daemonizes and is hence reparented to

Yes, but at this point init(8) can't do anything with those error
codes. It would have been different if there was a launcher interface
where the launcher could babysit a child and error numbers could
provide a primitive communications channel. But there are better
and more rich ways to communicate.

>And when it does not daemonize, it is in debugging mode, and providing
>an information that the program has, and that will be lost when casting
>all errors to EXIT_FAILURE, is a debugging feature...

Most people don't expect to look at exit values for debugging, and then
find the information in sysexits(3).

>Not to mention that if there was the user interface equivalent of
>strerror(3) (a sysstrerror(1)), one would not have to plague the programs
>with variable strings, more or less accurate.

Yes, and the place for programs to print that status would be shells.
Unfortunately none of them do.

>And, if a daemon was reparented to a daemon server, not closing stdin,
>stdout and stderr, but redirecting then, this will allow to pass
>commands to the server via its stdin, solving the problem that was
>discussed, incidentally, in the course of the inetd(8) thread. And this
>super daemon could make something of standardized return statuses if
>only for stats purposes.
>sysexits(3) is a good idea. And this is probably why it hadn't caught

Well, everyone has a right to their own opinion.


Home | Main Index | Thread Index | Old Index