Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cos!fetter From: fetter@cos.com (Bob Fetter) Newsgroups: comp.unix.misc Subject: Re: Globbing Message-ID: <43995@cos.com> Date: 28 Feb 91 04:55:46 GMT References: <1991Feb18.152347.28521@dgbt.doc.ca> <474@bria> <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu> <481@br Reply-To: fetter@cos.UUCP (Bob Fetter) Distribution: na Organization: Corporation for Open Systems, McLean, VA Lines: 40 In article kers@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-