Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!alberta!arcsun.arc.ab.ca!arcsun!kenw From: kenw@skyler.arc.ab.ca (Ken Wallewein) Newsgroups: comp.arch Subject: Re: shell architecture (to glob or not to glob) Message-ID: Date: 13 Feb 91 18:55:44 GMT References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> <360@bria> <1991Jan17.185527.9824@Neon.Stanford.EDU> <365@bria> <378@bria> Sender: nobody@arc.ab.ca (Absolutely Nobody) Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 34 In-Reply-To: mike@bria.UUCP's message of 21 Jan 91 00:05:53 GMT A side note. If the command has a syntax known to the agent that does the globbing, and the program that receives the command knows where the globbing has taken (or should take) place, there can be a significant increase in command flexibility and power. Ever notice that all Unix commands that support globbing only allow it at the end of the command, and only allow one (possibly list) argument to be globbed? That's why you can't say mv here/* there/* for example. There are a number of ways to approach this, when command parsing is done cooperatively between the program and the system. Globbing could be done before the program receives the command line, wherein it is passed a more complex data object than a simple string or array of strings. It could be passed a reference, or a handle to a call-back routine -- in which case, the actually globbing could occur at various times. If the facility is used to parse commands entered while the program is running, this provides a handy capability. I sometimes think that shell-based command line globbing is a violation of the Unix "one tool, one job" philosophy. And a kludge, at that. It presumes to know something about the syntax desired by the program. -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca R E S E A R C H (403)297-2660 C O U N C I L