Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!alberta!cpsc.ucalgary.ca!arcsun.arc.ab.ca!arcsun!kenw From: kenw@skyler.arc.ab.ca (Ken Wallewein) Newsgroups: comp.arch Subject: Re: Globbing Message-ID: Date: 3 Mar 91 03:45:31 GMT References: <43994@cos.com> <1991Feb28.225426.24072@jarvis.csri.toronto.edu> <1991Mar2.035219.21905@Think.COM> Sender: nobody@arc.ab.ca (Absolutely Nobody) Distribution: na Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 27 In-Reply-To: barmar@think.com's message of 2 Mar 91 03:52:19 GMT In article <1991Mar2.035219.21905@Think.COM> barmar@think.com (Barry Margolin) writes: >... > I agree. On Multics, we decided that there were a few commands that need > to be able to take any file name that the kernel could handle. The > "rename" and "delete" commands accept a "-name" option followed by a > pathname, and they ignore a loading hyphen and don't glob that parameter. > We felt that it was not important to make it easy to operate arbitrarily on > files with screwy names, but it was important to make it easy to *fix* the > names. > ... Fascinating. I don't know Multics, although I've heard some very interesting things about it. That approach has depth -- it handles both globbing and option recognition override. But it wouldn't work with common "dumb" implementations of shell globbing, would it? What does Multics use? And how does it handle such filenames if they contain spaces? Perhaps it would be reasonable to have globbing shells recognise something comparable; a variation on the escape character perhaps, that works on whole arguments or lines. If the program parsers recognised the same escapes, it might address these problems. -- /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