Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.os.misc Subject: Re: shell architecture (to glob or not to glob) Message-ID: <3147:Mar601:42:3491@kramden.acf.nyu.edu> Date: 6 Mar 91 01:42:34 GMT References: <1991Mar3.020451.5596@metapro.DIALix.oz.au> <19503@cbmvax.commodore.com> Organization: IR Lines: 61 In article <19503@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Unfortunately, the user must know in advance if a glob will result in > -xxx filenames BEFORE invoking the command, or must always use -- on all > command lines. What would happen someone created a file named -r in a > directory where you often delete some files with *, or *.c, or whatever? Fact: Any path that doesn't start with / can be prepended by ./ without change. (Actually, I don't like this separation into cases; there are many situations where it would be convenient to have a single character that means go back up to root, *anywhere* in a filename. Then doubled slashes wouldn't be a problem, and you could prepend ./ no matter what.) In any case, if you want the shell to do this for you, no problem. > BTW, according to the man page I get for rm, it doesn't follow > your standard: it wants rm - -ha.ha. That is generally regarded as a bug. Keith Bostic says that BSD 4.4 will fix such things. > What if there was a match? The point is that it's an output spec, > not an input one, and therefor shouldn't be matched against existing files. Exactly. Therefore it is not shell globbing. It is pattern matching. That's what regexp libraries are for. > >As I mentioned before, all the shells I know of, allow you to turn off > >globbing. > > An implicit admission that shell globbing can get in the way at times. > It's painful to turn it off just because you want to run a specific command. Be serious. "*". > You can get around most any annoyance with enough work, quoting, etc. > However, which is better for the user? Indeed, is it better to have a single, uniform interface that works for everything users want to do (except find and mvm, and then simple quoting suffices)---or to give users what will invariably feel like an inconsistent interface since programmers will have different opinions on what should be globbed and what shouldn't? > However, I think it > produces a far better and easier to use interface for the user of the > system. Prove it. Nobody comes up with any answer to this except multiple-file rename, and mvm handles that perfectly. > It also makes it easier to have a richer globbing language Be serious. It is easier to change a library routine and recompile all your programs (and don't pretend that shared libraries are used on most systems), or to change the shell? Has it occurred to you that two users might want different globbing conventions? All they have to do now is change the shell. In your world, they would have to change every single program that ``understands'' globbing. Can't you see why modularity is better? ---Dan