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

Previous Next

Full log

View this message in rfc822 format

From: Bruce Korb <bruce.korb <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 8090 <at> debbugs.gnu.org
Subject: bug#8090: strerror(1) and strsignal(1)?
Date: Sun, 20 Feb 2011 16:21:23 -0800

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

Previous Next

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