Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!cc1 From: cc1@locus.ucla.edu (Michael Gersten) Newsgroups: comp.sys.amiga Subject: Re: Pattern Matching & Shell Design Message-ID: <3728@curly.ucla-cs.UCLA.EDU> Date: Tue, 13-Jan-87 21:41:26 EST Article-I.D.: curly.3728 Posted: Tue Jan 13 21:41:26 1987 Date-Received: Wed, 14-Jan-87 03:01:13 EST References: <954@blia.BLI.COM> <1731@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: 229 Summary: Patterns: not much; shell: "That stinks, here's why:" >>> = 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. Sorry about that. Meyer. Mike. [discussion of how the shell can tell what and how to expand] >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 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. 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 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 is not very good. As an example, consider DATE. imagine this... DATE 11:30 (shell): TIME arg required, enter: (DATE can take TIME, DATE or DATE, TIME for its args; but the list would (and does) have to specify one). Or, DATE (shell): DATE and TIME args required, enter: when DATE is happy to just print out the current date. In other words, some program will do one of many different things, and interpret arguments in many different ways, based on number/types of arguments. 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'. But, this is fixed, i.e. you can't say set noglob oddball df0:c/* = df1:c/* set glob or oddball df0:c = c1:* c2:* c3:* where A) is similar to PIP while B) is similar to cp (yes, this seems far-fetched right now, but this is off the top of my head) >>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) >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. 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)) >>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. [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) >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). 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) Well, I'll try that ASSIGN when I get home >>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 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. So, It can be done, it can be done easily, ergo, it should be done. (Note: I did not say, "Put everything into the kernel"; I said "Put it into the kernel if the kernel can do it easily". I also feel "Put it into the kernel if it can't be done at all any other way" (this applies to exec(), which is extremely hard to impossible to do under AmigaDos. Fexec() is not exec) >Of course, you still have to deal with the problem of "list par:" >saying "packet request type unknown". Or is that a bug, also? No, list would send a packet asking for file names, par: would say, "Say WHAT?", list would reply 'par:' or 'Not a file system' or something like that. >>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." 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, 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) >>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). 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. Consider mv i=(f? ~rem/uucp/cki*) o=~/uucp to mv f? ~rem/uucp/cki* ~/uucp 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) >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. > >