On 5/7/23 04:20, G. Branden Robinson wrote: > 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
Oh yeah, those. I guess I can't argue much against that practice then.
I still haven't burnt a copy of them yet. :D
>
>> 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.
Heh, I was talking a bit from memory, and I forgot that perror(3) is so
basic. In fact, I normally use the err(3) and warn(3) family of
functions, which are similar to perror, but accept a printf-like
format string. err(3) also has exit(3) functionality.
For some reason I wrongly remembered that perror prefixed the output
with program_invocation_short_name(3), which the BSD functions do.
>
> So strerror(3) seems better to me.
I've written some small comparison of the functions I use and similar
ones I know of.
$ cat error.c
#include <bsd/err.h>
#include <err.h>
#include <errno.h>
#include <error.h>
#include <stdio.h>
int main(void)
{
errno = 1;
perror("perror");
warn("%s:%d: %s", __FILE__, __LINE__, "warn");
warnc(errno, "%s:%d: %s", __FILE__, __LINE__, "warnc");
error(0, errno, "%s:%d: %s", __FILE__, __LINE__, "error");
error_at_line(0, errno, __FILE__, __LINE__, "%s", "error_at_line");
}
$ cc -Wall -Werror error.c $(pkgconf --cflags --libs libbsd)
$ ./a.out
perror: Operation not permitted
a.out: error.c:12: warn: Operation not permitted
a.out: error.c:13: warnc: Operation not permitted
./a.out: error.c:14: error: Operation not permitted
./a.out:error.c:15: error_at_line: Operation not permitted
error_at_line(3) seems to have a syntax similar to what you use.
It's curious that error_at_line(3) cannot be implemented via error(3).
>
> 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.
>
Maybe the functions shown above can be used to appease your wrath?
Cheers,
Alex
> 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
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
OpenPGP_signature
Description: OpenPGP digital signature
