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
