Globbing
Bob Fetter
fetter at cos.com
Thu Feb 28 15:55:46 AEST 1991
In article <KERS.91Feb26095613 at cdollin.hpl.hp.com> kers at hplb.hpl.hp.com (Chris Dollin) writes:
>
>"Turning off globbing would make existing programs harder to (re)write?" (said
>at least once). Bloody hell.
>
>extern int glob_the_lot
> ( int argc, char **argv, void mainly( int argc, char **argv ) );
>
>int main( int argc, char *argv )
> {
> return glob_the_lot( argc, argv, original_main );
> }
>
>Somebody writes glob_the_lot and makes it available. Assorted people make
>trivial changes to code. End of story. The difficulty resides in making sure
>that the changes happen consistently on given platforms.
You forget that the entire reason for putting this into the executables
is *not* to offload mindless globbing from the shell, but to put in some
sense of -semantics- into the globbing process.
What one might expect from executable globbing is that there would be
a understanding of the context in which the globbing is to take place.
I can imagine a command:
read_mail *.net_mbx -only_from *.RMT-HOST -subject *glob*
which could (in my imagination) read mailboxes, performing a globbing
operation on all '*.net_mbx' mailboxes, passing arguments which select
mail items from users on a system named 'RMT-HOST' (assuming RFC-822-esk
structure) and wanting only those messages which have the string 'glob'
somewhere in the subject line.
Nuke city with a shell globber.
Now, this is only in my imagination on Unix. Elsewhere, now, it's a
different story. Whether this is a 'good thing' in today's Unix world
is yet another question.
-Bob-
More information about the Comp.unix.misc
mailing list