Globbing

[Bill Hacker]

er_reader.dragonflybsd.org>	<47b34981$0$856$415eb37d at crater_reader.dragonflybsd.org> <20080213203349.e9caf15b.steve at sohara.org>
In-Reply-To: <20080213203349.e9caf15b.steve at sohara.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 90
Message-ID: <47b35e26$0$848$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 218.253.81.177
X-Trace: 1202937382 crater_reader.dragonflybsd.org 848 218.253.81.177
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12129

Steve O'Hara-Smith wrote:
> On Wed, 13 Feb 2008 19:48:16 +0000
> Bill Hacker <wbh at conducive.org> wrote:
> 
>> 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?
> 
> 	It would have to be a shell builtin

An assumption based on legacy.

 > otherwise the shell is going to
> expand the wildcard and try and stuff it into an execve call and that's
> where things fall over.

Not if the shell is not involved (in that portion).

> Alternatively the new xrm would have to use a glob
> syntax completely different to the shell glob syntax, or at least require
> quoting globs, which would open a whole new can of worms.
>

Quoting the glob expression is hardly onerous. No need for yet-another 
sin-tax.

pkg_add -rv rpl

man rpl

Note the '-s' option.

Similar tool to grep, or grep and sed'ing inplace, but 'handier' in a 
human-friendly sort of way for those who so seldom use the traditional 
Unix tools that the syntax is a major chore to remember or look up.

Remember - coders - who work with the traditional tools every day of the 
week - are not particularly representative of the admin community, let 
alone the growing number of end-users who are exposed to Unix via 
now-practical desktops - or simply webalized maintenance 'reach' into 
limited parts of a server.

> 	I've been caught this way too and I'd love a solution but it's not
> easy to provide given that the shell does the globbing.

It *can* do.

But that can be prevented / diverted easily enough.

Mind - there is more to it than just the rm or the globbing issue.

The larger picture is a new set of predictable CLI tools for 
large/heavily populated fs that can be safely called from <wherever> - 
GUI's included.

If interactive warnings, confirmations, waits for input et al are wise - 
let them be defaults, possibly with a -q and -f or -o for scripting with 
quiet/forced/over-ride behaviour. (Though I don't see scripting as the 
primary target - the legacy tools may well be better suited for that).

If such tools have to work in batches to avoid outrunning memory - that 
is neither surprise nor a particular drawback.

Handy if the chunking is done is some increment size that aligns with 
other system resources - inodes or fractions thereof, for example.

Better an 80% fast utility easily remembered and with built-in 
protection than a faster one that needs hours to research and vet before 
it can be turned loos safely.

The many other options mentioned in the course of this thread are in no 
danger of disappearing. Unix never throws *anything* away - just kicks 
it around 'til it gets lost.

;-)


> I've often thought
> that was a mistake but if so it's a hard one to unwind at this stage.
>

I don't see the need to unwind it at all.

Easier to side-step it.

'more' still exists on most systems that also have 'less', and - though 
I personally wouldn't use it at gunpoint - I've given up trying to 
remove 'vi' from the system as a waste of my time.

Bill