GNU bug report logs - #8090
new programs: strerror(1) and strsignal(1)?

Previous Next

Full log

Message #20 received at 8090 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Korb <bruce.korb <at> gmail.com>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: Jim Meyering <jim <at> meyering.net>, 8090 <at> debbugs.gnu.org
Subject: Re: bug#8090: strerror(1) and strsignal(1)?
Date: Mon, 21 Feb 2011 07:38:59 -0800

Hi Jim, Alan, et al.,

On 02/20/11 16:52, Alan Curry wrote:
>> remains for the itchy folks to drag something around to new places
>> whenever they go to a new environment......
> 
> The important thing is that when you need to use this utility, you report a
> bug on the program that printed a number instead of calling strerror(3)

That might be a little less convenient than grepping through
`find /usr/include -name '*errno*.h'` results.

>> Nice.  I've copied them into my shell functions directory.
>> I still think strerror(3p) ought to imply a strerror(1) command,
>> but I leave it to you to decide.  It's just my preference.
> 
> Just as write(2) implies write(1), and time(2) implies time(1). Or something
> like that.

"write" isn't right because it serves a different function.
"time" is also different.  There's no getting around the fact
that being proficient requires remembering a lot of stuff.
My point is that the less you have to remember, the easier it is.
So you need to convert an error code into a humanly comprehensible
string.  When writing "C", you call strerror().  In user space,
what command requires less to remember?  Either "errno" because
there's a header by that name and there's a global variable that
often holds the value by that name, but there is also the
library conversion function strerror and there is strsignal(3).
If you include strsignal(1), then strerror(1) is consistent.
Just do not pick "describe --fserror 11".  ;)

Anyway, the choice between errno(1) and strerror(1) is pretty marginal.

As for whether it ought to be a coreutil or a devutil, it's no
big deal either way to me.  I just think it probably ought to be
provided one way or another so we don't have so many re-inventions
of code-to-string translation programs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.