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: <2104@jade.BERKELEY.EDU> Date: Wed, 7-Jan-87 02:48:14 EST Article-I.D.: jade.2104 Posted: Wed Jan 7 02:48:14 1987 Date-Received: Wed, 7-Jan-87 18:44:07 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Organization: Missionaria Phonibalonica Lines: 145 In article <3549@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >> = Mike Myers Uh, since I'm Mike Meyer (not plural, and add an e), and I said these things, I think I'll correct the attribution. >>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. It can if it's told what they are. See the article I posted a couple of days ago that's a draft of "A Shell for Modern Personal Computers," which describes one way of doing just that. >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 The above paper does it a different way, which avoids these problems. >>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. MicroShaft and SCO are selling AT&T software (either V or III, nowadays. I don't think anyone is still selling v7), so chances are you are seeing AT&T bugs. My experiences with MicroShaft are such that I'd expect them to introduce a whole new set of bugs without fixing any of the old ones. [End obligatory large software vendor bashing.] >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. I've used that trick before, but that's a kludge. Ls is nicer, and nearly as fast on well-run systems. With only ONE argument, I'd much rather have completion. If you can get to a 4.3 system, do "set filec", and then try typing escapes in the middle of file names. If you can't do that, get a copy of microGNUEmacs, and play with typing spaces at prompts for buffer and command names. >3 with bogus semantics. Thats one STRONG reason for this stuff to >be in a common subroutine library or by the shell. It's even better to put it where the user can play with it. See the above-mentioned posting. >>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) Almost every time I use sed, I have to go out of my way to quote the arguments. Without filename expansion, this wouldn't be a problem. Other expansion tricks hurt other programs. Of course, you probably do what I do, and make sure things never have the magic characters in them. We have odd restrictions on the names in our CMS system because of oddities in the Unix shell! >>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. Huh? You mean you can create a device gort/foo: ??? How about gort/my_foo:, then do a "list gort" to see the devices in it. I think not, but could be wrong (never had a reason to do anything THAT bizarre). >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 *** I don't think it's a bug report - I think it's confusion on your part. Have you ever worked with a large system which had similar features (TOPS-10, VMS, and probably others)? On those systems, devices (and system logicals) ARE NOT part of the file name space. Then again, they tend to have ugly three-part file names: device, followed by a magic character; a directory path, with magic characters at both ends, and finally a file name. Probably split into a name and an extension, with a magic character seperating. Compared to such kludgyness, AmigaDOS is nice Of course, you still have to deal with the problem of "list par:" saying "packet request type unknown". Or is that a bug, also? >Actually, I think they should be FULLY integrated, and if they aren't, >blame Dos; if they are, blame the BCPL programs. I tend to think they aren't fully integrated, and think that DOS should be blamed. But it's hard to blame the designers: they did that work before Unix really became popular, and the way they did it was the way almost everyone else was doing it back then. "Blame it on TRIPOS." >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. You don't have to quote it if the command is doing the expanding instead of the shell. You seem to have ignored the possibility of it being shortend to o=fi*, also. And o= isn't noticable harder to type than > (to key presses, either way, on the Amiga keyboard). Of course, the shell can do all of this for you. See the afore-mentioned posting for details. >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. Yes, but we got to the shell doing it via totally different paths. You started wanting a dumb shell, ala Unix, that just expands everything. I started wanting more intelligent handling of arguments. Making that user-configurable pushes things from the command to the command processor. See the much-mentioned paper to see where that leads you, and how FAR that is from a dumb "file-expand-every-argument" shell. If that posting hasn't gotten to you by the time you see this, something probably broke. Please let me know.