DragonFly kernel List (threaded) for 2008-02
DragonFly BSD
DragonFly kernel List (threaded) for 2008-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Globbing (was Re: HAMMER update 10-Feb-2008)


From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Wed, 13 Feb 2008 16:23:45 +0000

talon@lpthe.jussieu.fr wrote:
Bill Hacker wrote:

Matthew Dillon wrote:

    hours while csh eats up all the memory on your machine and everything
    comes to a grinding stop.  It doesn't work.

People need to learn to use find, xargs, awk, etc.

-Matt
Matthew Dillon
<dillon@backplane.com>

All manner of insects have been found preserved in amber, so why not a DragonFly?

But they didn't *choose* to be fossilized.


Bill, i agree completely with Matt.

I don't *disagree* with him myself.


It's his dime, his project, and is at least less arcane than Plan9.

> Of course you can increase the size
of the buffer so that more globbing stuff fit in, since machines have bigger
memories nowadays. But there will always exist side cases where one needs
to be more sophisticated. Moreover using globbing to removes thousands
files at one stroke exposes us to the famous 'rm a *' instead of 'rm a*'
which certainly occurred at least once to each of us. Taking time to think
about one wants to do, and how to do it, is better than using blind
automatisms. And if you have carefully crafted names in your files you may
end up removing far more than you wanted using globs, where find has
special construct to fight against this trick ( -print0 ).


That is a reasonably accurate history lesson. No argumant.


But it is largely irrelevant to the actual presnt-day challenge.

Managing modern fs of the size that *coders* conceive, design, implement, but that only real-world *users* manage to actually fill up *overnight*, and admins then have to deal with. All too often.

The point is not to argue over the legacy of tools we've outgrown.
I understand how deeply embedded 'rm' and friends are in, for example, buildworld and siblings.


The point is to build *new* tools that *can* manage greater resources as we build those greater resources.

So 'rm' is no longer the right tool - or even a safely re-usable name.

But neither is some 'awk' ward script construction.
Those are even less safe or predictable - even in reasonably expert, but often 'too tired' hands.


So what is the point of a multi-terabyte fs if only a coder - or at least a 'script mavin' can *manage* them?

Are we to divide them up into tiny chunks just so the traditional tools can work? Hack a 'Midnight Commander' clone in userland?

I hope not.

As to 'rm /path/to/dir/*' .... or 'rm -Rf /path/to/dir/*'

Well.... if one doesn't understand what that particular 'pattern' is expected to match, relying on early breakage of small buffers is not a good enough safety anyway.

;-)

Bill



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]