Newsgroups: comp.os.misc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Subject: Re: Globbing Message-ID: Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC References: <17602@lanl.gov> <18205@lanl.gov> <18365@lanl.gov> Date: Thu, 21 Mar 91 17:58:24 GMT In article kenw@skyler.arc.ab.ca (Ken Wallewein) writes: > So what you're saying is that it's better for programs not to glob, because > that way you can totally bypass the globbing mechanism if you want to. Exactly. > That makes a lot of sense. But it has a lot of limitations, too, as have > been well described in this discussion. It means that you have to be able to tell the shell not to glob, for the relatively uncommon case where file globbing is not what you want. > It seems to me that we must consider shell globbing to be a tool somewhat > separate from the shell per se, which assists us in giving file names to > programs. A standard library routine for performing globbing is a must, but I don't see that it changes the arguments in favor of doing shell globbing. > I agree that quoting/backslashing can be a royal pain -- especially when > one is trying to define aliases. However, I think that it is a broader > issue that globbing; rather, that it is a shell design issue which affects > the use of metacharacters in general, not just those used for globbing. Agreed. Globbing is a side issue: it changes the magnitude of the "problem", but it hasn't created it. > Once that is removed, the problem of when expansion occurs is greatly > reduced, although not eliminated. Once what is removed? The use of metacharacters in shell syntax? I don't think you can do away with that without abandoning the idea of having the shell as a programming language altogether. I am not prepared to do that. You can always abandon shell programming, and have (as you say) a separate preprocessor that does the preprocessing and calls the "real shell" to do the work, but I would say the resulting pair of programs will continue to be used as the shell. The "new shell" will be little but a loop calling execv... and you already have that tool available. > What's wrong with that? As far as I'm concerned, the file system calls > _should_ be able to expand expressions, "~", variables, etc., the same way > thay handle soft links and (in VMS and AmigaDOS) logical names. But the semantics of file system calls are different. "Open" returns a single file token (handle, LUN, whatever). Which of the 47 matching files foes it open for "*.c". I've used a system (on CP/M) where the runtime did this very thing, and the resulting program behaviour was confusing to say the least. As for a complete syntax for command arguments, see "parseargs", recently posted to comp.sources.misc. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"