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
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."
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.
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)...
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...
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.
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.
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Home |
Main Index |
Thread Index |
Old Index