DragonFly kernel List (threaded) for 2008-02
er_reader.dragonflybsd.org> <47b34981$0$856$415eb37d@crater_reader.dragonflybsd.org> <email@example.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Trace: 1202937382 crater_reader.dragonflybsd.org 848 22.214.171.124
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12129
Steve O'Hara-Smith wrote:
> On Wed, 13 Feb 2008 19:48:16 +0000
> Bill Hacker <firstname.lastname@example.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
pkg_add -rv 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> -
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.