Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.arch Subject: Re: Globbing Message-ID: <19375@cbmvax.commodore.com> Date: 1 Mar 91 07:46:21 GMT References: <19217@cbmvax.commodore.com> <5573:Feb2307:19:4491@kramden.acf.nyu.edu> <19336@cbmvax.commodore.com> <17704:Feb2719:04:3791@kramden.acf.nyu.edu> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Distribution: na Organization: Commodore, West Chester, PA Lines: 106 In article <17704:Feb2719:04:3791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> If the program does the globbing, dealing >> with a command of the form "foo A* B*" is trivial. > >It is trivial as is. Why do you want this separation into two sets? What >conceivable function of foo would require A* and B* to be treated >separately? Are A* and B* supposed to be ``corresponding'' sets in some >way? They will usually not have the same size. Because some commands may not wish that all of the parameters be globbed. For example, the infamous "rename *.foo *.foo.old" (rename==mv). Yes, the user can work around it with escape characters, but this can be a royal pain, and requires signifigant understanding of exactly how the shell does things (which is why many things, like "find", and some of the trickier uses of the CShell are absolutely opaque even to people who use Unix every day, but aren't gurus). >Even if you do have some reason for such a foo, you will always survive >with foo [options] -- A* -- B*. -- cuts off all option processing and >will make a perfectly good separator. This imposes a very specific syntax on commands. What do you do in a keyword-oriented system? Also, allowing options anywhere is far more regular and less confusing to users. >and I encourage you to write a shell that supports such globbing if you >can figure out a good syntax. Poof, done: VOS on Stratus (if I remember right), and AmigaDos (and probably others). >Yes, changing the shell does mean changing the shell. Surely you agree >that this is easier than modifying every single program. I thought we were discussing software architecture here, not Unix (tm) shells. For that, we should be in comp.unix.shells, or whatever, not comp.arch. Just because it is unlikely to become part of standard Unix doesn't mean it's not a better way, or interesting. >Do you realize how much time it takes to quote arguments? A program >might spend several seconds constructing a million-byte argument list. >It is insanely inefficient to have to quote that list again and again >for each program that sees the arguments. You must have missed some important reference, this makes no sense to me. >Good. I'm glad you understand the advantages of shell globbing. Do you >realize how much work it takes to do the same thing in every program? >Just one mistake and boom, you have a program that doesn't glob. UNIX >isn't meant to load all these requirements on programmers. That's a really silly and spurious argument, IMHO. Turn that argument against argument parsing and you would say that the shell should do that also, because if someone didn't use (for example) getopt() then you'd have a program that didn't accept "normal" options, etc. If globbing is a system function, it's really trivial to use (easier than getopt()). >> How does shell globbing help me in a dialog >> box? > >Your shell handles the dialog boxes. Nah, too easy. Nah, too confusing/hard/expensive/etc/etc. Shells are good at interpreting commands and running programs, which has nothing to do with a good file requester. If all you're using it for is as a globber, why not put globbing into the system and have things that want to glob call that? Using a shell just for globbing is like going to get the mail from the mailbox (50 feet away) in a ferrari. >> Or, for a simpler problem: I have a program for the Amiga called >> DiskSalv. It scans over a damage disk and extracts recoverable file. If >> you don't want them all, you can specify a pattern to search for: > >I understand what you're saying here. You're not talking about globbing. >You're talking about a pattern-matching problem with superficial >resemblances to globbing. He's saying that with shell globbing, anything that needs pattern- matching is going to require extensive quoting to keep the shell out of the hair of the program, and user will have to do it. >> >4. The system is slow enough as is without every application scanning its >> >arguments multiple times and opening up one directory after another. >> It's no slower for the program to do it than for the shell to do it. > >Look, either you have every program looking for arguments to glob, or >you leave globbing in the shell. The first alternative is necessarily >less efficient whenever you pass arguments to more than one program. Tell me how I invoke multiple programs at once with the same argument list. The only way I can see is to stuff the globbed names into a variable and then use that - which can be done regardless of whether the shell globs all command-lines. BTW, I have written shells with globbing and without, and ones with command-dependant globbing. I find the best mix is programs do the globbing through the system, and the shell does globbing only on demand (an expand command and an interactive expansion ala tcsh). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)