Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Newsgroups: comp.sys.amiga Subject: Re: Pattern Matching & documentation Message-ID: <1908@jade.BERKELEY.EDU> Date: Thu, 11-Dec-86 21:43:02 EST Article-I.D.: jade.1908 Posted: Thu Dec 11 21:43:02 1986 Date-Received: Sun, 14-Dec-86 19:24:13 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <3237@curly.ucla-cs.UCLA.EDU> <3313@curly.ucla-cs.UCLA.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Organization: Missionaria Phonibalonica Lines: 78 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? >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. >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. >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. >So, the problem isn't that it should be done, the question is who >should do it. As a user, I don't care AS LONG AS ALL COMMANDS DO IT. Sorry, but as a user, I want the pattern matching to work against the set of objects with the same type as the argument. I don't really care who does it either, but it's going to require some work on the part of the programmer NO MATTER HOW YOU DO IT. >As a programmer I prefer to have it done for me. As a pesimistic >observer, I note that many people won't do it unless it is as simple >as 'PatternMatch (argc, argv)'; even then, some still won't. I'd like to have it done for me, too. But I'd much rather be able to do it right than have the CLI impose an arbitrary mechanism on me. >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 with abbrevs (Dillon's shell does abbrevs, at least for built-in command names. Nice going, Matt). That's kind of redundant with shell redirection. Nice for users who don't like the cryptic "type >filename ", though. Of course, if the shell is doing file name expansion, then you loose the ability to grab the output name by pattern. >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?