[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8090: strerror(1) and strsignal(1)?
From: |
Alan Curry |
Subject: |
bug#8090: strerror(1) and strsignal(1)? |
Date: |
Sun, 20 Feb 2011 19:52:42 -0500 (GMT+5) |
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