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

Giles Orr gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Fri Aug 24 15:57:00 UTC 2012


On 23 August 2012 16:56, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On Thu, Aug 23, 2012 at 3:48 PM, Ben Walton <bdwalton-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> Having interacted with the coreutils (and the underpinning gnulib)
>> folks a bit, I'd almost bet that a new option as opposed to changing
>> the meaning of an existing one is the only way forward there.  Getting
>> any new option introduced to the coreutils programs requires a well
>> written proposal and most of the time the code to back it. :)
>
> My sense on this is that it would be nice if only we could step back
> in time and eliminate some of the usages of /bin/ls, and be able to
> change its behaviour to be a bit more sensible.
>
> Rob Pike recently (January) twittered something a bit analogous about rm:
>
> Rob Pike ‏@rob_pike
> rm: dir: is a directory. Seriously, guys? It's 2012 and rm still can't
> remove a directory? You should be ashamed.
>
> This gripe turned into a big "oh, but POSIX doesn't specify it that
> way!" fight.  Or, to quote him directly:
>
> "Most of the responses were of three forms: teaching how to use rm,
> which I already know how to do, or telling me to setup an alias for rm
> -r (which is dangerous and not at all what I want), or telling me it's
> necessary for compatibility. My point was not made, but then I didn't
> really expect it to be."
>
> What he *really* meant, that it's safe and easy to change rm to remove
> an empty directory without requiring flags and without giving an error
> that reminds me to run a different command, rmdir.
>
> Unfortunately, "the horse has long, long, long, long bolted."  People
> are *so* attached to thinking that directory deletion and file
> deletion require different commands, or that /bin/ls behaves in a
> given way that we probably have to treat these behaviours as givens
> that Can Not Be Changed despite being pretty stupid.
>
> 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.

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.

-- 
Giles
http://www.gilesorr.com/
gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
--
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





More information about the Legacy mailing list