Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!mit-eddie!genrad!decvax!decwrl!hplabs!felix!scgvaxd!stb!michael From: michael@stb.UUCP (Michael) Newsgroups: comp.sys.amiga Subject: Re: Pattern Matching & documentation Message-ID: <825@stb.UUCP> Date: Sun, 28-Dec-86 17:15:31 EST Article-I.D.: stb.825 Posted: Sun Dec 28 17:15:31 1986 Date-Received: Tue, 30-Dec-86 21:38:16 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <1908@jade.BERKELEY.EDU> Organization: STB BBS, Los Angeles, CA Lines: 114 Summary: ... In article <1908@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: > In article <3313@curly.ucla-cs.UCLA.EDU> cc1@locus.ucla.edu (Michael Gersten) writes: > >What I did was just what you did--namely, pass a *@* to the finger > >program. If it doesn't know how to handle this, is that my fault? > > If it's ok for finger to do it's own pattern matching, why isn't it ok > for list, dir, etc. to do their own pattern matching? > One moment. If you are talking about a program that is designed to work with something that the CLI cannot possibly see, then the command can pattern match. If you are working with something that the CLI can see, then the CLI should expand it. > >As for shell scripts, I'm not sure I understand the question/complaint. > > Consider a shell script: > > for i in $* > do > echo $i > done > > which acts like echo, but puts each word on a seperate line. Now, try > convincing it to echo a "*". Notice that your quoting mechanisms don't > work right. Very simple. set noglob foreach i ($*) echo $i end That does it, no? > > >ONLY 4 or 5 BCPL commands work with patterns; list uses a BRAIN-DAMAGED > >form of matching that can only check the current directory. > > How many of the rest of them use file names? Does it make sense for > them to do pattern matching if they aren't dealing with file names? > And you're right, list is brain-damaged. Here is a quick look at c: and the programs that use files: Assign AddBuffers CD Copy delete diskchange echo ed edit execute fastdir filenote info install join list makedir 'newcli from' path relable search run sort type Z (manx editor) > > >I feel that the CLI should properly handle *:file (ops, #?:file) things. > >In fact, I tried doing a DIR #?:, and got a requester for a disk. > > Not clear that shell file name expansion should handle assigned names, > as they are not part of the file system. On the other hand, if you're > doing pattern matching, then it doesn't matter that they're not part > of the file systems. Those commands that need to deal with them can. > On the contrary, they are part of the file system. AmigaDos recognizes them, does it not? Next thing you know, you'll claim nil: is not part of the file system. Would you claim that /dev/null is not part of the file system? [comments about the ease of having the shell do it vs. the desire for odd programs to do it their own way] > >Finally, I *HATE* programs that assume that their first filename is > >for input, and the second one is output. TYPE is that way. I lost > >several files that way (do NOT say read the manual; I did, and that > >was NOT clearly pointed out) > > Gee, I didn't have any problem with it. But I'd much rather have something > that looked like > > type outfile=filename > > Of course, if the shell is doing file > name expansion, then you loose the ability to grab the output name by > pattern. > Oh yea? What about cat *.c > exist* where there exists a file called existensialistic_programming_fun > >Lastly, what do font names/process names have to do with file expansion? > > Look at the subject line: it says "Pattern matching", *NOT* file > expansion. That's the point - not every command deals with files, and > having your command processor act like they do is a crock. Wouldn't it > be nice if you could use the exact same regular expressions for > commands that dealt with processes (or font names) as you do for > commands that deal with files? WITHOUT having to quote them. Or do you > find consistency a problem? > >