Forking coreutils, WAS Re: A Generation Lost in the Bazaar - Poul-Henning Kamp article

[Lennart Sorensen]

On Fri, Aug 24, 2012 at 11:57:00AM -0400, Giles Orr wrote:
> On 23 August 2012 16:56, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> > More entertaining was the discovery that .hiding .files .by .putting
> > .a .dot .on .the .front represents an outright bug that falls from a
> > bad string comparison when looking for directories that was introduced
> > in System 2, and which persists to this day.
> >
> > Either Ken or Dennis made this mistake, of coding (in assembler) the
> > equivalent of:
> >    if (name[0] == '.') continue;
> > rather than
> >    if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;
> 
> If we can't change it under its current name, perhaps the "correct"
> thing to do is to fork rm as "nrm" (the New ReMove).  With different
> and saner switches and no bugs-that-are-now-features.

That was a shell bug, not an rm bug.  nrm will still have to deal with
. files being special.

> This works for higher profile projects like Firefox and Libre Office,
> but there's a persistent problem: utilities like "rm" just aren't
> glamorous enough and are far too well established.  Since open source
> programmers are working for personal interest and recognition but not
> for cash, they tend to go for the glamour.  And things where they
> actually think there will be some interest from others.  The
> probability of anyone creating a successful fork of rm and/or
> coreutils is slim, even if anyone had the wherewithal to do it.  The
> only really successful fork of something that low level that I can
> think of was LPRng - which sprung out of pretty broad agreement that
> LPR was too much of a dinosaur to live.  And I'm not hearing that
> about rm or coreutils, not yet.  Just some mild grumbling.

Who would try to use nrm when it isn't present on all systems the way
rm is?

The "problems" you suggest fixing aren't even accepted by everyone as
being "problems" in need of "fixing".

As for successful forks.  Well gcc, glibc (at least it is looking fairly
successful so far), links, cdrecord, and probably some others.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists