bug#8090: strerror(1) and strsignal(1)?

[Bruce Korb]

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.