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

[Bruce Korb]

Hi Jim,

On 02/20/11 15:20, Jim Meyering wrote:
> Bruce Korb wrote:
> Hi Bruce,
> 
> [your subject mentions strsignal -- you know you can get a list
>  via "env kill --table", assuming you have kill from coreutils? ]
> 
> I've had that itch many times.
> Here are some handy bash/perl functions I wrote:

Yep.  I know one can get to it via perl.  OTOH, _you've_ had that
itch many times, Padraig's had that itch many times, and I'd take
a wild guess that there have been a few others, too.  So it still
remains for the itchy folks to drag something around to new places
whenever they go to a new environment.  Were it in "coreutils",
it would likely be more easily found.  It also fits well with my
pet theory that library function names ought to have same-named
commands lying about.  Thus, if you can remember strerror(3p),
then by golly there's a strerror(1), too, with obvious options
(none, in this case) and operands.

(Aside, that program handles strsignal with "-Dcode_to_text=strsignal"
on the command line.)

>     $ errno-find 11
>     EAGAIN
>     $ errno-int-to-msg 11
>     Resource temporarily unavailable
>     $ errno-sym-to-int EAGAIN
>     11

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.

Cheers - Bruce