Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!batcomputer!llenroc!cornell!uw-beaver!ubc-cs!alberta!arcsun.arc.ab.ca!arcsun!kenw From: kenw@skyler.arc.ab.ca (Ken Wallewein) Newsgroups: comp.os.misc Subject: Re: Globbing Message-ID: Date: 7 Mar 91 04:13:08 GMT References: <1991Feb18.152347.28521@dgbt.doc.ca> <474@bria> <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu> <19336@cbmvax.commodore.com> <43994@cos.com> Sender: nobody@arc.ab.ca (Absolutely Nobody) Followup-To: comp.os.misc Distribution: na Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 88 In-Reply-To: peter@ficc.ferranti.com's message of 28 Feb 91 21:05:28 GMT Here is an excerpt from a side conversation via mail: >...the fact that UNIX *programs* treat arguments beginning > with "-" specially has nothing to do with globbing; globbing treats > such arguments exactly like all others. Of course. But the very fact that globbing takes place, coupled with the possibility that files may have names starting with "-", means that by the time a program gets its command line, it may have no way of knowing _for_ _sure_ whether an argument is a user-entered command line option or a globbing- generated filename. And that ambiguity is a result of the logical interaction between globbing and argument parsing in an environment where filenames can contain virtually any character. One needs, I think, some syntactical rules which are followed by both globbing and parsing, so they can work properly together. We have those now, in fact; but I don't think they have been sufficiently developed. As has been pointed out before, a globbing mechanism that understood command syntax could be very powerful -- although are some difficulties with that approach, too. Other people have mentioned that one can take advantage of Unix's file specification semantics (the "./" trick) to avoid some ambiguities. Certainly this will work -- in Unix -- but I'm trying to to talk "globbing theory" in as general a context as possible, without skirting issues or presuming a file semantics context. Peter, you asked me to come up with other examples besides the mv/rename one. To be really meaningful, such a command would need to have multiple separate wildcard file specifications, all of which need to be globbed by the shell. For there to be a point to this, there would probably need to be some relationship between the files on the two lists. It wasn't easy; they don't exist now, as far as I know -- maybe due to a chicken-and-egg precedence problem -- but here are a couple: difff [args] spec1 [args] spec2 [moreargs (why not?)] Such a program would compare all the files/objects referred to on "spec1" to corresponding files in "spec2". The args may contain expressions controlling how the comparison should be done and how correspondence is determined. Now envision this occurring in an environment where filenames may contain spaces, leading "-"s, and other pathological characters. Another example might be one wherein one set of files is used to process another set of files -- a glorified 'make' or 'xch', perhaps. The syntax would probably be comparable; I don't plan to go into it in detail. And I don't plan to defend it from arguments that it could be done another way. That's not my point. My point is the difficulty in doing it _this_ way. What if globbing were turned off by default, and one escaped or quoted an argument to make it glob? I have the impression that that has been tried and abandoned. Does anyone know why? Parsing difficulties and the loss of command line information would be greatly lessened if globbed arguments were passed as a list data object rather than as in-line text. There _are_, after all, syntaxes for specifying arbitrary sets of characters in delimited strings; sed and vi do it. All we really need to do is chose one. Even though my exerience is (surprise, surprise ;-)) primarily in non- shell-globbing environments, I think I like shell globbing better. One can rely on it always being there, as opposed to environments where programs may or may not have availed themselves of it. And your point about being able to hand a program a literal filename, and not have the program try to expand it, is a good one. Some systems provide shell parsing and program globbing; some the reverse. Like socialism and free enterprise, each has its absolute adherents. Me, I want it all :-). But maybe it's pointless to debate the niceties of a command line interface, when it may soon be that only software and programmers will use them, and everyone else will use GUIs. /kenw -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca <-- replies (if mailed) here, please R E S E A R C H (403)297-2660 C O U N C I L