Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!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: <2073@jade.BERKELEY.EDU> Date: Thu, 1-Jan-87 03:32:37 EST Article-I.D.: jade.2073 Posted: Thu Jan 1 03:32:37 1987 Date-Received: Thu, 1-Jan-87 19:05:06 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <1908@jade.BERKELEY.EDU> <825@stb.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Organization: Missionaria Phonibalonica Lines: 171 In article <825@stb.UUCP> michael@stb.UUCP (Michael) writes: >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. Uh, if a program can see the names, why can't the CLI see them? After all, it's just a program. More importantly, how is the CLI supposed to know what it should or shouldn't expand, and what that expansion should be against? [Good old shell scripts again!] >Very simple. > set noglob > foreach i ($*) > echo $i > end > >That does it, no? Very nice - much better than the "$@" solutions, as those don't work on all shells. Of course, in either case you have to depend on the programmer who wrote the script to do it correctly. Experience tells me that neither AT&T nor Berkeley will always get it 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. > >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 disagree - many of them deal with devices, not files. Part of them aren't standard utilities. Echo doesn't deal with files, just words. If you delete these things you have left: assign CD delete ed edit execute filenote join list makedir newcli path search run sort copy type In addition, assign, cd, execute, newcli, and run only deal with one file, and it only makes sense for them to deal with one file. They should complete, not pattern match. I don't know if ed and edit deal with multiple files, so I'm going to assume they don't (add two further on if they do but don't pattern match.) Makedir and filenote don't accept multiple files, but should. Sort and type have the broken from/to semantics. Path, search and join should do pattern matching, but don't. List does patterns (brokenly), delete, copy and search do patterns correctly. In summary: 7 commands for which multiple arguments don't make sense; 2 for which they do, but don't support them; three with bogus semantics; three that don't support pattern matching but should, and three that do things right. Or 10 for which it can be argued that things are done right, six for which things are done wrong. You really thing unix does that much better? I suspect that over half the commands have arguments that don't deal with files, which makes their command line handling (as far as I'm concerned) wrong. >> >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? It appears that one of the really nice features of Unix has confused you. You see, /dev/null is TWO things. Firstly, it's part of the Unix file system; or more accurately, it's in the Unix file system namespace. It can be any arbitrary file. I can put data in it, take it back out, grep for things in it, and have it all work; like so - Script started on Wed Dec 31 23:42:50 1986 eris# file /dev/null /dev/null: character special (3/2) eris# mv /dev/null /dev/save.me eris# echo hello > /dev/null eris# cat /dev/null hello eris# rm /dev/null eris# mv /dev/save.me /dev/null eris# file /dev/null /dev/null: character special (3/2) eris# ^D script done on Wed Dec 31 23:43:38 1986 On the other hand, the file named /dev/null *BY CONVENTION* points to a trivial device. The ability to have arbitrary filenames point to arbitrary devices is a major win for Unix. AmigaDOS isn't so nice, device names are magic; they aren't files, they are DEVICES. To see the difference, try listing par:. Or how about copying df0: to a single file in RAM:? Odd, it won't do it. Unix does reasonable things for both of these attempts. So I just made your prediction come true; nil: isn't part of the file system. It's part of the OS, so of course AmigaDOS recognizes it. Symbolic names that point to a directory are something else again. A nice feature (that Unix ought to have, and done better than VMS), but they confuse the issue. >> 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* Sorry, but "> exists*" is NOT "outfile=filename". One is short and cryptic, the other nice and readable. Done right, you'd input "o=fi*" (or something similar) in the second case, but could write it out longhand for scripts (where readability can be important). [A description of pattern matching versus filename expansion] >OK, Now I understand what you are driving at. But here is one major question >for you: > >How will you do it? >At some point, you have to have a routine that takes ARGV, ARGC, and a list >for pattern matching. How are you going to do it so that it can easily >do file, font, library, device, message ports, active tasks, etc, etc, etc. Well, there are a couple of ways. One would be to provide a single subroutine that took three arguments: argv, argc and a description of what the arguments should look like (that last may take more than one argument; possibly varargs code needs to be used). It could either twiddle argc and argv (which would violate the ANSI standard) or you could call it multiple times (try "man 3 getopt" to see what I mean). Other library combinations are possible. However, I've decided that the shell should do it, based on command description files. The main reason for this is that it gives the user LOTS of power in tailoring the interface. I've just realized that you could still do it in a library and give the user that power. On Unix, the result would (almost certainly) be an ugly hook to find the correct description file. AmigaDOS might work better though. Have to go think about it. >For anything based on an exec node list, its not hard. But not everything is. Not much harder than doing file expansion. The hard part in every case is getting a list of all the objects in the "universe." And any of the above approaches means that it only has to be done once (barring reinventing the wheel). The shell description I've mentioned that talks about all this (among other things) has been written. I realized that it would be suitable for publication in SIGSmall/SIGPC, and wrote it for that. I'm going to be uploading the result in the next day or two, and will post a draft here.