Paul Eggert wrote:
mwoehlke writes:
I'd like to jump in and make a comment here... I have coreutils (5.97)
built on nine different platforms, but haven't even attempted to
tackle procps as it is not auto*-based (and so far I have not been
motivated to track down how to set up the build correctly, much less
chase down bugs and build errors). Unless procps is fixed/improved,
dropping these from coreutils means - from my POV - that they will be
gone entirely.
I know of no plans do drop them.
That was the impression I got from Matthew Burgess' post; apparently
that is non-authoritative?
'uptime' is a bit of a curiosity. On my platform (Debian stable)
coreutils 'uptime' does its work with fewer system calls than procps
'uptime', so I don't know why anyone would prefer procps uptime.
(Maybe someone else can chime in.)
For 'kill', most people use Bash's 'kill', not coreutils's or
procps's, so they probably don't care about 'kill' one way or another.
At some point I was planning to merge coreutils 'kill' back into Bash
but it's low priority.
A good point, however a number of people around here use csh instead of
bash, so I think it is still valuable (to me, anyway).
'su' is the only one we're thinking of dropping from coreutils. Do
you use coreutils 'su'? 'su' is so intertangled with security gorp
that these days it's pretty hard to port separately from the rest of
the gorp.
Doesn't look like it; it seems 'su' didn't get built on *any* of the
systems I built coreutils on (even Linux? ...but I might have done that
intentionally and just forgot). At any rate, I know 'su' is problematic
and don't object to dropping that one. Certainly not if you're only
dropping it from non-Linux builds (since it sounds like some other
people would mind it going away entirely).
--
Matthew
'$ time make world' -> real 5d:14h:37m:5.291s user 0m:0.000s sys
4d:2h:14m:43.712s
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
