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

[Alan Curry]

Bruce Korb writes:
> 
> 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? ]

What's the installation rate of coreutils-kill vs. procps kill? Debian
chooses procps kill (except on Hurd and maybe freebsd-kernel)

> > 
> > 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

You guys don't perl-golf well.

perl -E'say$!=11'

or for older perls

perl -le'print$!=11'

> 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.

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)
itself. Error numbers are not a user interface, regardless of Microsoft's
attempt to train people otherwise.

> 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.

-- 
Alan Curry