A Generation Lost in the Bazaar - Poul-Henning Kamp article

[Lennart Sorensen]

On Thu, Aug 23, 2012 at 04:56:37PM -0400, Christopher Browne wrote:
> 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."

So rm -r is dangerous, but an exception for empty directories is not?
Why?  What if a directory only containts other empty directories?
Is that safe to rm?  How far does the exception have to go?  How about
directories with only 0 byte files in it?  Can it remove those?  If not,
why not?

> 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.

A directory is NOT a file and rm by default does an unlink which removes
one link to an inode from a directory.

rm is a user interface to unlink().  rmdir is a unser interface to
rmdir().  unlink simply removes a hard link to an inode and doesn't have
to check anything else.  rmdir has to do a bunch of checking before it
is able to remove a directory.

I think it's a good thing that rm doesn't try to guess what you meant.
I like that unix systems do what I say, not what it thinks I meant.
If I don't say what I mean, that's my problem.

And changing rm is NOT safe.  Some people are used to the fact rm only
removes files so doing rm * will remove files, but not directories.
If you change it you break stuff that currently has a known expected
behaviour.

> 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.

They are different, so using different commands makes sense.

> 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;
> 
> People started using hidden files for things, going as far as the
> fictional case, in DecWars, where Con Solo used this bug to hide the
> heroes from the Administrative Flunkies, and so we can't get rid of
> that blemish.

That's neat.  I had not heard that before, but it sounds quite plausible.

> These are very much "Bazaar" bits, and we've got plenty of them.  And
> it takes some "cathedralizing" to clean them up that amounts to
> heading over to the Plan 9 'ghetto', or something of the sort.  As
> much as there are attractive things about Plan 9, there's no port of
> Firefox or Chrome, so most people find that an unacceptable choice.

-- 
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