Oliver Fromme wrote:
*snip*
.... In fact, I think it is cool
that the ancient UNIX tools are still perfectly suitable
to manage todays resources.
I submit it would be more 'fair' to say
'..no LESS suitable than they ever were..'
;-)
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.
That is actually part of what I've been on about...
With few exceptions, all a GUI does is put a pretty face on a tick-box
that invokes the same underlying binaries a CLI shell would use.
With server, DB, and MTA admin what it is, I probably spend 80% of my
at-the-screen time on the GUI's of OSX or a *BSD SSH'ed to somewhere
else in a terminal shell.
So - does a Gnome, KDE, or Xfce4 interface get around the issue?
I think not.
Especially when it is not local to the box that GUI runs on, but a
far-end *BSD server being admin'ed via an SSh login - and all the GUI
has given you is a terminal with nicer colors, cut 'n paste et al.
Far end server is still limited to a <whatever>*sh shell and the 'local'
binaries *it* owns.
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 submit that this is because we have (all?) been thinking about
extending the old tools instead of going about the job a different way.
Blinders, in a manner of speaking.
After all, if use of find or xargs accomplishes the task w/o ill effects
on memory, then what prevents creation of a compiled utility that has
that same sort of 'flavor' of approach - just hard-wired from the get-go?
Similar to the 'copy' vs 'xcopy' of long ago....
'xrm' maybe?
I suggest that those people who _do_ see a problem make
a patch and submit it for review.
Given the many valid (if uncomfortable) reasons already put forth for
NOT messing with 'rm' (Or execv(). Or the shells), I think a patch to
any of those would (and should) be rejected as potentially a great deal
more harm than good.
However .. that may simply mean that a new set of file management utils
is more appropriate.
Ones that cannot break a legacy useage they do not have.
And that these should 'ship' with the new fs(en).
Or perhaps be built-in API's?
> 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):
??
Those features predate Unix itself, let alone zsh.
$ 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
Yeah .. well..
try that, over an ssh connection, on a 180 GB UFS(1) mount that has
reported 100% full at only 3/4 of blocks used ...
.because the *number of filenames* (in a single 80 GB+ dirtree in this
case) has hit the limits the OS supports.
Bring lots of patience, and return with a suspicion that some things in
Unix-land are not as up to date as they might be...
;-)
Bill
