Globbing

[Bob Fetter]

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-