In article <zkfw3g+sf5uwa...@polynum.com>, <tlaro...@polynum.com> wrote: >Le Sat, Jul 01, 2023 at 06:39:32PM -0000, Christos Zoulas a écrit : >> In article <20230603120221.0766b60...@jupiter.mumble.net>, >> Taylor R Campbell <campbell+netbsd-tech-userle...@mumble.net> wrote: >> >> Date: Sat, 3 Jun 2023 13:45:44 +0200 >> >> From: tlaro...@polynum.com >> >> >> >> 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
