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 Meyer) Newsgroups: comp.sys.amiga Subject: Re: Pattern Matching & Shell Design Message-ID: <2213@jade.BERKELEY.EDU> Date: Thu, 15-Jan-87 04:39:18 EST Article-I.D.: jade.2213 Posted: Thu Jan 15 04:39:18 1987 Date-Received: Thu, 15-Jan-87 22:30:34 EST References: <954@blia.BLI.COM> <1731@jade.BERKELEY.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike Meyer) Organization: Missionaria Phonibalonica Lines: 288 In article <3728@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >>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. > >Ok. There are several problems with your shell. >#1: windows >#2: non flexible parameter passing #1 is a matter of taste. #2 is a misunderstanding of what was in the paper. We'll talk about them both. What you actually get is a stripped-down macro processor layered on top of a Unix-like facility. >Windows: I can accept one window for normal work (both shell output and >command output and my input). I can accept a second window for history. > >But I will not accept seperate windows for talking to the shell, another >for talking to my program, and yet a third for history. Why do you assume there'll be a second window for talking to your program? Unless it opens one, the shells input window should work for it. Just like csh/sh/ksh on Unix. Better yet, the history mechanism should work for input to things other than the shell, unless it does raw/cbreak mode stuff; *much* better than any Unix shell does (unless you're running it in an Emacs, of course). If it doesn't do line-oriented input, it's probably got it's own window, and you'd have to deal with that no matter WHAT shell you ran. >I do not program >with the mouse. Have you used AmigaBasic yet? I tried, but the thing has >SOOO MUCH excessive use of the mouse that I cannot get comfortable >with it. I'm afriad that your shell will be smilar No, I haven't looked at AmigaBASIC. But that's a matter of taste, and I even mentioned it towards the end. You don't have to use the mouse, but it'd make your life more painfull. I *do* program with the mouse. Once again, get a copy of mg, and look at the mouse interface I desgned (both the editor hooks and the browser are my design. Mic did a lot of work to make them nicer; except for taking the names off the mouse keys so can get both mouse keys and function keys), then notice that I have changed things so that Echo-Mouse does a "save-buffer", and you'll quickly realize that I can go through a short edit session without ever typing characters. And I've done so. >As for parameters, whats wrong with a program determining the type of >its parameters based on the type of previous parameters? For such a >program, an explicit list of 'arg1, arg2, arg3 required, arg4' or what >not very good. As an example, consider DATE. Yeah, I know. And you almost reached the correct conclusions: >Now, since your shell requires that whether or not args are exanded is >FIXED (a big complaint of mine) and not changable, how do you handle >such a program which can take varying args, etc. Answer: you don't. You >say, 'Do no arg checking or exansion', or 'Do no arg checking, but expand >filenames'. Well, almost right. You can tag the two arguments as optional, possibly with keywords, like so: command date optional date expand date single optional time expand time single Assuming the shell understood the date and time universes. That way, you could type things like: date yesnoo and it would set the date to noon yesterday. Much nicer than the Unix shells. Admittedly, putting date/time matching into the shell isn't going to be usefull for very many things, so it's not likely. >But, this is fixed, i.e. you can't say > >set noglob >oddball df0:c/* = df1:c/* >set glob And what makes you think that you can't do that? Of course, I wouldn't make it so ugly, having set noexpand and unset noexpand. Better yet, a command/argument completion character that says "don't expand the preceeding." Thus saving you the trouble of doing the set/unset. >>>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. > >Ls is never 'as fast'. It has at least a program startup overhead, and it >has to fstat each file to see how big it is >(my ls is alias ls lf -s) I said "nearly" as fast, and on well-run systems. You get to the point where IO overhead (to the disk, then to the terminal) is the bulk of the time. You're also assuming that "echo" is a built-in, which is a fairly recent development in Unix shells. Of course, if you're adding the fstat, you're putting an unfair handicap on ls. You could also break some shell scripts, depending on where you do the alias. Not well-written scripts, but we've done AT&T and BSD bashing before. >>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. > >Completion sounds like real time expansion. If so, great, I'll take it. For the shell I proposed, it's real-time expansion. In most places, it isn't, as you're limited to only one "expansion." >But again, what if a command may take one item one time, or a lot of >items another time? (now I'm thinking of a copy program which would either >backup a disk or copy files depending on its args (trs-80 model 1)) So? I don't see any problem. You describe it as a repeated arg, then select a single device, or multiple files. Maybe you'd better describe it in more detail. >>>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. > >But the user can play with it if there is an ordered list he can work >with. Huh? Please expand on this. >[discussion of unix file-expansion] > >>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! > >Ok. I just quote the arg to awk and sed automatically, since they expect >their arg to be in one of the argc/argv positions, not spread out over >two or three (If I'm wrong, my apologies, but I've never checkd, and always >assumed this to be the case) Nope, they aren't. They check for things after other arguments, and similar oddities. Admittedly, they expect a single argument for them, with other arguments keying them in. If the shell weren't doing expansion (and variables, and loads of other things), this quoting wouldn't be needed except for spaces. >Hmm, I've never tried this, but I think >A: the mount as gort/my_foo: would work >B: the list gort would fail >C: a list gort/#?: should work, but probably won't (since DIR doesn't >expand device names, I don't think list will) I don't think they will work. Even if the mount works, those ARE NOT file names, they're device names. Devices aren't in the file system name space; some devices support it. Some even support it with different semantics (consider a list of "CON:100/100/*/*")! More logically, consider the semantics of a remote-mounted CP/M file system, or some other creature. It'd still be "DEV:filename." >Nonesense. AmigaDos requires all of its handlers to support common >READ and WRITE packets; exec requires all devices to support common >CMD_READ and CMD_WRITE messages. So, why not expect that if AmigaDos >knows that vdisk.device, unit #2 is called by filesystem-handler under >name VD2:, then Dos knows both a handler and a device, and can get >the proper thing sent out. Uh, you left out the hard part. How do you decide, under certain conditions, which is "the correct thing"? Even Unix can't handle that. Either something is a file, or it's a directory, and copying them does different things. DF0: is a device and a directory; the program dealing with it has to make assumptions about it. Or maybe you can provide an algorithm that'll work? >The point is, things must evolve. Look at what unix has done. Look at >what BSD has done. Ok, don't look at what Bsd has done. Look at what >V8 is doing (or the rumors that I hear say they are doing). In short, What I've been saying all along. It's just that we disagree over which direction things should go :-). Oh, yeah - you should look at what BSD has done. The two most interesting Unix developments going on are based on BSD (MACH on 4.3, and v8 on 4.1). And there are some good things in BSD (just because the code is buggy, and the kernel makes me want to regurgitate doesn't mean it's all bad). The single most important thing that UCB CSRG did with BSD was to not give a shit where things came from, and steal them if they were worth stealing. Finally, you should also look at OS/9; it strikes an interesting balance between Unix and Tripos/AmigaDOS. There are probably others I've missed (MINIX, Ameoba, V, Locus, Domainix, and others come to mind). >No, I don't expect to see unix on the AMiga >Yes, I think Meta-comco should look at unix and borrow the better stuff, >OR SUPPORT EXEC LIBRARY FORMAT so we can change AmigaDos ourselves. Right >now, we are stuck with it, so it should not have these problems. > >Flame off (sorry) One of the nicest things about Unix (well, early in it's life, anyway), and also one of the worst things about it, was that it came with source, and you could fix things to be the way you wanted them. The lossage was that everybody did things their way. At one Usenix (SF in '80, I think), they had a questionaire asking "What interesting things have you done to the kernel (Don't bother to mentioning tty driver hacks)?" Everybody tweaked the tty driver, and in different ways. This type of things was (and still is) rampant. I miss that facility in AmigaDOS (but not much. I get more than enough systems hacking to make my living, thank you). The interesting things about Tripos/AmigaDOS (and OS/9, for that matter), is that the pieces can be added without having to fool with the exec. For example, the pipe: driver that's floating around (love it, love it, LOVE it. Got a CLI script I'm going to post shortly; the pipe: device makes it go LOTS faster, and you can do things you can't do in Unix!) >>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). > >I said this was religeous. My complaint is that the programmer has >significantly more work to do, the syntax is not as nice, varios minor >things, etc. The programmer doesn't have to have more work to do; it depends on what kind of support environment you have. Consider VMS or getopt on Unix. Niceness of syntax is a matter of taste, and will depend heavily on what you were brought up on. As someone put it, the really nasty thing about Unix is that a generation of programmers is being brought up thinking that the user interface isn't worth thinking about, and that user-friendlyness is for lusers. >Consider > >mv i=(f? ~rem/uucp/cki*) o=~/uucp > >to > >mv f? ~rem/uucp/cki* ~/uucp True, the = isn't right for everything. But it sure makes life a lot nicer for the things that it *IS* right for. For instance, I'd love to have a symlink command that had those things. It's arguments are backwards compared to the rest of the Unix world. The best trick is to support (as I suggested in the paper) both position and keyword driven arguments. In the shell, not a library, so the user can get to them. >and others. Besides, if there is an o= to replace >, you have to worry >about a file named o=file1 being mentioned but not seen. (Yes, thats >pushing. But you mentioned filename restrictions from the unix shell) Huh? Why so? Just type o=o=file1. The shell should have put "output=o=file1" on the command line for you to see, though. >>If that posting hasn't gotten to you by the time you see this, >>something probably broke. Please let me know. > >I will have to re-read it, and give some more comments on it. They'd be appreciated. The above has made me realize one thing: The alias facility really needs to let you twiddle args, so that you can have different restrictions on them. For instance, date might look like so: command setdate alias date required date optional time command settime alias date required time command date optional date optional time Which lets you have argument-driven versions of date to set the date and time. Figureing out how to work that into a cshell-like mechanism for the "alias" builtin may be a bitch, though.