Globbing

[Bill Hacker]

ater_reader.dragonflybsd.org>
In-Reply-To: <47b32337$0$847$415eb37d at crater_reader.dragonflybsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 124
Message-ID: <47b34981$0$856$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 218.253.81.177
X-Trace: 1202932097 crater_reader.dragonflybsd.org 856 218.253.81.177
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12127

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