Re: Globbing

[Oliver Fromme <check+jw6r4i00rsmj6aiy@xxxxxxxxxx>]

Bill Hacker wrote:
 > 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.

Yes, but that's not a new problem.  It was always like
that.  It has nothing to do with "modern fs".

I hit the argmax limit when I started with UNIX 20 years
ago on a 60 MB disk, and learned to use xargs(1).  It's
no different today.

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

rm(1) works perfectly well today, just like 20 years ago.
There is no problem at all with rm(1).

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

I don't think that's true.  In fact, I think it is cool
that the ancient UNIX tools are still perfectly suitable
to manage todays resources.

People who write shell scripts will have to learn what
xargs(1) does, and what it is good for.  People who don't
want to learn how a command shell works will use graphical
file managers.

I don't see any problem there.  At least not a problem
that could be easily solved without creating much bigger
problems (like kernel memory exhaustion).

I suggest that those people who _do_ see a problem make
a patch and submit it for review.

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

I completely agree.

zsh happens to have a nice feature that you can press <TAB>
on a glob expression, and the shell will expand it on the
input line.  So you can see what files are affected before
pressing enter ("_" is the cursor position):

$ ls /etc/mo*_
Pressing <TAB> updates the line to this:
$ ls /etc/modems /etc/motd _

I use that feature very often, especially when working in
/tmp or other world-writable directories, and when using
destructive commands like rm.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd