DragonFly kernel List (threaded) for 2008-02
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Trace: 1202932097 crater_reader.dragonflybsd.org 856 126.96.36.199
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12127
Oliver Fromme wrote:
> .... 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....
> 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
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...