Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!ucla-cs!cc1 From: cc1@locus.ucla.edu (Michael Gersten) Newsgroups: comp.sys.amiga Subject: Re: Pattern Matching & documentation Message-ID: <3549@curly.ucla-cs.UCLA.EDU> Date: Sat, 3-Jan-87 00:02:06 EST Article-I.D.: curly.3549 Posted: Sat Jan 3 00:02:06 1987 Date-Received: Sat, 3-Jan-87 03:36:47 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> <1908@jade.BERKELEY.EDU> <825@stb.UUCP> <2073@jade.BERKELEY.EDU> Sender: root@ucla-cs.UCLA.EDU Reply-To: ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) Organization: Ucla Computer Club (disclaimer) Lines: 170 (Posting from ucla because stb isn't receiving news during the holidays) > = Mike Myers >> = Me >>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? Very simple: it doesn't, and can't. However, files should be matched against files, fonts against fonts, etc. But, the CLI can't tell what it is, or can it? It can guess, i.e. foreach type (type-list) foreach arg (arg-list) match (type, arg) end end or something similar. The problem: A. Different people would want different orders in type-list B. Different people would want different things in type-list C. Some things may be hard to put into type-list >[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. I agree, and Microsoft and SCO aren't much better. >>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. Here we have some disagrements. I feel that ANY time a program deals with files, it should be expanded, even if it is only one file (like CD). As for non-standard, thats only Z and fastdir. Besides, echo does deal with filenames--on Unix, I use it as a fast ls to see if a file exists. >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 > ... >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 3 with bogus semantics. Thats one STRONG reason for this stuff to be in a common subroutine library or by the shell. >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. Hmm.. I can't think of a command for which the file-name expansion hurts me. Mail and history are a different problem (bang bang) [discussion of devices/disk names, should they be expanded] >>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 - [example of using /dev/null to refer to something else] >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. Well, lets see. I can mount arbitrary device handlers with arbitrary Dos device names, but I can't unmount. So, the only restrictions are that I can't avoid the colon at the end, and I can't change a name once gdven. As for copying df0: to ram:, or TYPE DF0: TO DF1:, or something: I belive this is a fault of the BCPL programs doing checks that they shouldn't be checking. If I am wrong, *** BUG REPORT *** And it REALLY should be fixed for 1.3 (speaking of which, I've found about 4 bugs in 1.2 so far. Will send them out in a week if no others show up) >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. > Actually, I think they should be FULLY integrated, and if they aren't, blame Dos; if they are, blame the BCPL programs. >> >>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). I don't know about you, but I HATE outfile=x type things. Absolutely HATE. DO NOT put that into amiga dos. Religious fight up ahead 8<) Besides, quoting > is easy: \> or '>'. Quoting 'outfile=file*' is not as easy, and you have to get it to expand and then ignore the outfile= part. [Comment about how to do file expansion] Well, we both agree that the shell should do it. We both agree that it should be user configurable. Soon, we'll have something we both hate equally--that will be it. Michael Gersten Best reply: backbone!ucla-cs!cepu!ucla-an!remsit!stb!michael scgvaxd!stb!michael is not reliable right now Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.