Re: Prefix for warnings (was: device-dependent warnings)

[G. Branden Robinson]

Hi Alex,

At 2023-05-03T01:26:55+0200, Alejandro Colomar wrote:
> > troff:man3/unlocked_stdio.3:123: warning [p 2, 1.8i, div '3tbd1,0', 0.3i]: 
> > cannot break line
> > 
> > an.tmac:man4/cciss.4:164: style: blank line in input
> > 
> > man4/console_codes.4:324: warning: table wider than line length minus 
> > indentation
> 
> I find it more readable when there's one space between the program
> that generates the warning and the file.  That's what mandoc(1) does,
> and in general, what any program that relies on perror(3) does (I'm
> assuming mandoc(1) probably calls perror(3) or similar).

I'm following the GNU Coding Standards here.

https://www.gnu.org/prep/standards/standards.html#Errors

> I suggest adding such space, which BTW would allow you to call
> perror(3) in some cases.

Long ago (25 years?) I decided that I hate perror(3) and resolved to
never use it, but the problem may have been that I saw it used badly,
omitting the name of the running program--possibly in Troan & Johnson's
_Linux Application Development_.

Without taking the time to work back through an example to remind myself
of the details of my antipathy, I think the problem I had was that
perror() did the printing itself.  But for its output to be useful and
not hatefully anonymous, you needed to build a const char *
first...probably using C standard library functions that themselves
would set errno.

So strerror(3) seems better to me.

I've lots and lots of junior engineers and/or bad extant (but
shipping!) code throwing perror() around carelessly.  I hate, hate,
hate, hate anonymous diagnostic messages.  Whatever replaces Unix one
day should use a proper logging facility instead of a standard error
stream--but one that is easier to use than syslog(3).  syslog(3) itself
is fine but it needs an interface for novices and doofuses.

In fact, making perror(3) that interface sounds great to me.  Open the
log, write the message--recording its PID and argv[0] for all time--and
close the log.  Hell, I'd scoop up the UID and TTY (if any) as well.

logger(1) is a similar idea that isn't carried quite far enough; it is
similarly missing TTY information.  Way better than nothing, though, and
better than perror(3) due to its persistence.  logger is under-used in
shell scripts IMO.

Regards,
Branden

signature.asc
Description: PGP signature