Path: utzoo!mnetor!tmsoft!torsqnt!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: 14 Feb 91 21:06:14 GMT References: <378@bria> <1991Feb14.024803.1252@Think.COM> Sender: nobody@arc.ab.ca (Absolutely Nobody) Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 79 In-Reply-To: barmar@think.com's message of 14 Feb 91 02:48:03 GMT In article <1991Feb14.024803.1252@Think.COM> barmar@think.com (Barry Margolin) writes: > independent of the command. More to the point, though, you can glob as > many arguments as you want, and they can be anywhere on the line. For > instance, I've done things like > > find foo/* bar/* -name "*frob*" -print Syntactically, "foo/* bar/*" is a single list argument. Granted, though, it wasn't the last argument on the line. See below... > > That's why you can't say > > > > mv here/* there/* > > You can say it, but it won't do what you probably hope. The wildcards are > expanded, and then all the pathnames are passed to the mv command. The > command doesn't see the original wildcards, so it can't treat them > specially. The above command is exactly equivalent to > > mv here/file1 here/file2 here/file3 there/filea there/fileb Thank you -- that was exactly my point. 'mv' has no way of knowing which of the original arguments were globbed. That is potentially valuable information about the syntax of the original command which is lost to the program. I submit that if globbing were not done in such a way as to loose this information, mv _would_ have been written to do what you correctly assumend was my intention (it was, as intended, intuitively obvious). And even one used quotes, mv -- and most other programs -- don't take advantage of that. Presumably because the parsing would be difficult, which is precisely to the point. > Your reference to "only at the end of the command" is probably is probably > confusion about the fact that most Unix commands have syntax of the form > > command -options files Well, no, it wasn't. > This is merely a common syntax convention; it makes it a little easier to > parse the arguments, because it can stop processing options as soon as it > sees the first argument that doesn't begin with "-", and then simply loop > over the remaining arguments. The find command is a good counterexample. > Another example of a command where the globbed argument is likely not to be > the last one is mv: one of its allowed syntaxes is > > mv -options file file file ... directory > > (this moves all the files into the directory). It is quite common to use > wildcards in the file arguments, e.g. > > mv here/* there/* nowhere > -- > Barry Margolin, Thinking Machines Corp. All good points, Barry, and thank you for responding thoughtfully rather than simply rushing to the rebuttal. I especially like your point that it is _possible_ to separate multiple globbed arguments while working with a simple shell globber. But I think you have made my point, in that the sophicated parser and awkward syntax required to do so mean that it is only done in rare cases, and then not in a consistent manner. I think better parsing and command syntax definition tools might go a long way to correcting this. On the other hand, am _I_ missing the whole point of the Unix Way to even want this? Certainly there are workarounds -- shell loops, etc. The questions is, are those workarounds really the Right Way, the way of Truth, Beauty, and Simplicity? Or are they merely kludges? /kenw -- /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