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

[christos%astron.com@localhost (Christos Zoulas)]

In article <ZKFW3g+SF5UWaNTf%polynum.com@localhost>,  <tlaronde%polynum.com@localhost> wrote:
>Le Sat, Jul 01, 2023 at 06:39:32PM -0000, Christos Zoulas a écrit :
>> In article <20230603120221.0766B609AC%jupiter.mumble.net@localhost>,
>> Taylor R Campbell  <campbell+netbsd-tech-userlevel%mumble.net@localhost> wrote:
>> >> Date: Sat, 3 Jun 2023 13:45:44 +0200
>> >> From: tlaronde%polynum.com@localhost
>> >> 
>> >> 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
>absolutely
>no bearing on the usefulness of NetBSD. Only on the stupidity of the
>mob.

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
>init(8)...

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
>on.

Well, everyone has a right to their own opinion.

christos