Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.os.misc Subject: Re: Globbing Message-ID: <21655:Mar2019:31:2791@kramden.acf.nyu.edu> Date: 20 Mar 91 19:31:27 GMT References: <18365@lanl.gov> <18511@lanl.gov> Organization: IR Lines: 87 In article <18511@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: > In article , peter@ficc.ferranti.com (Peter > da Silva) writes: > |> What you're saying makes perfect sense in an ideal world, but that's what > |> I've been saying all along. In the real world, you have to assume that > |> the program you're passing stuff to might decide to glob it. > If I don't know what a program is going to do with its arguments, > I ain't a-goin' to use the program!! Period. The problem is that there are lots of programs (from ``nice'' and ``find'' on up) that are documented to pass some of their arguments to other programs. Do you expect them to whip out the man pages for those other programs and figure out whether they should quote or glob or what? Perhaps you also want these programs to ftp the documentation if they can't find it locally. And fix your coding mistakes. And fetch your newspaper in the morning. > |> In article <18365@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: > |> > [... lots of nested quotes or repeated escape symbols ...] > |> Sounds like the programmer screwed up somewhere. I've never had to nest > |> more than two quotes. [...] > Then, you've never sent arguments to shell scripts which in turn > invoke shell scripts, which in turn invoke shell scripts, ``Peter, didn't you know that in an ideal world, there would only be ONE level of parsing for EVERYTHING?'' ``Wow, Jim, really?'' ``That's right, Peter, there's just ONE parser that handles key-up and key-down signals from your keyboard, tty handling inside your computer, command execution, argument processing, globbing, editing modes, compiling, and screen output formatting!'' ``But, Jim, that seems a bit monolithic. Wouldn't it be better to have each logically separate parser isolated inside a program of its own, the way that globbing is isolated inside the shell?'' ``No, Peter, NO! That is NOT how the world works! I don't want there to be multiple parsing levels, even when that makes perfect sense!'' ``But, Jim, if you want just one parsing level, then why are you saying that the parsing should be handled by every single separate program, instead of by just one program the way that globbing is done by the shell?'' ``Uh, um. Uh, um. Um. Uh. Um.'' > .... This > is a common practice on UNIX systems. Often, systems 'programs' are > implemented just that way. Good scripts do not glob or otherwise parse their arguments any more than good programs do. Just because you haven't used UNIX long enough to know how to use "$@" (really {1+"$@"}---the price you pay for backward compatibility) is no reason for you to shout religiously that the system is flawed. > In a command language, the most meaningful context for argument > evaluation is in the recipient. In _neither_ language should the > parameter passing mechanism do the argument evaluation. Jim is somehow saying that the shell's globbing is part of its ``parameter passing mechanism.'' That distinction is indefensible. > They are evaluated by the _shell_ NOT the _caller_. The _shell_ has > no business doing so. The _shell_ does NOT do it only once, it globs > every time an argument gets passed to it You are confused. The user has one shell, which does one level of globbing (which he can easily turn off). He may invoke programs which happen to be scripts written in sh or csh; if they glob their arguments (except those documented to be filename patterns), they are FLAWED, just like C programs that glob their arguments. > - which in a UNIX environment > may be very often indeed. So your colleagues write buggy shell scripts and tell you about them. Big deal. > |> [...] The shell is still a programming > |> language, however much you deny it. > I didn't deny it. But I will. The shell scripting syntax and semantics > do indeed constitute a language. But, the shell itself is an intermediary. > It is nothing more than a particularly poorly informed interpreter. If > the shell scritping language allowed arguments to be given _types_, then > the problem would solve itself: the shell could glob (once) any argument > which had the data type . Any other argument it would > leave alone. This would be a workable solution. Aha! So, after all this complaining, you admit that globbing should be in the shell anyway. You just want a shell with certain data types. Why didn't you say so in the first place? ---Dan