Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.os.misc Subject: Re: Globbing Message-ID: <19491:Mar1207:39:1391@kramden.acf.nyu.edu> Date: 12 Mar 91 07:39:13 GMT References: <17097@lanl.gov> Distribution: na Organization: IR Lines: 39 In article <17097@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > All you have to do is look at the assumptions that the > shell is making when it automatically globs and consider cases that > violate such assumptions. > 1) The case everyone thought of first: you want globbing to produce > _two_ distinct lists that correspond. This is the mv/rename > example that everyone has been discussing. And that is not globbing. > 2) You want an argument globbed, but _not_ in the context of the > local filespace. That is not globbing. > 3) You want the argument globbed, but _not_ in the context of a > filespace at all. That is not globbing. > After all, globbing is just a pattern matching > facility It is not just *any* pattern-matching facility. It is a *specific* pattern-matching facility, namely replacing a pattern with a (sorted) list of filenames matching that pattern. You have shown three cases where it might be useful to have a facility more powerful than globbing. Fine, go ahead and write such a facility. If people need it then they'll use it. (mvm has had reasonble success, and people might like a shell with similar syntax.) The current argument is whether it makes sense to put globbing into separate applications rather than the shell. Your examples are absolutely, totally irrelevant to that argument. They don't even support your religious arguments against UNIX, as anyone who's used mvm can attest. ---Dan