Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!alberta!arcsun.arc.ab.ca!arcsun!kenw From: kenw@skyler.arc.ab.ca (Ken Wallewein) Newsgroups: comp.arch Subject: Re: shell architecture (to glob or not to glob) Message-ID: Date: 13 Feb 91 18:37:33 GMT References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM> <360@bria> <1991Jan17.185527.9824@Neon.Stanford.EDU> <365@bria> <378@bria> Sender: nobody@arc.ab.ca (Absolutely Nobody) Organization: Alberta Research Council, Calgary Alberta, Canada Lines: 115 In-Reply-To: mike@bria.UUCP's message of 21 Jan 91 00:05:53 GMT In article <378@bria> mike@bria.UUCP writes: > This "special concise command language" is essentially what VMS has, and > what I argued against in the first place. Consider: > > 1. It does *not* simplify development, because it adds yet another > link in the already lengthy chain of project management Depends how complex your syntax is. In the case ANU News (a PD network news reader), for example, CDL plays an important role, and managing the syntax without it would be awkward. Simple programs would probably be better off without it. > 2. I *dont want* my command syntax decoupled from the program > because it tends to disrupt the continuity of the program, > and increases development and debugging time by adding "extras" > into the development phase. You gotta parse commands somehow. The question, as I see it, is whether the overhead of working with a more formal tool is too great for the size of your project. To me, that depends on how the tool is implemented. If you could specify the syntax of the command _within_ the program, that would be nice, I suppose. But what if it were in a subroutine call? Well, no big deal, I guess. But what if that subroutine were in a different language -- one optimized for command specification? Now we're starting to talk increased programmer overhead, and poor suitability for small projects. > 3. I *dont want* to call a parser or have my arguments spoon-fed > to me in a fashion that some external entity (ie: the shell) > decides that I sould receive them. I simply want a list of > arguments. The whole VMS approach, as snazzy as it may look from > the outside, can be damn frustrating when you are tied to it. > I speak from personal experience. Uh, I beg your pardon, but the VMS approach does _not_ "tie you to it". Command parsing can be done in several ways: as a separate command definition which is provided to the shell; as a definition which is instead compiled and linked to the program, to be called when needed; with no definition at all wherein you do all your parsing with whatever kludge you hack up; and variations in between. CDU even works for parsing commands entered WHILE THE PROGRAM IS RUNNING. In programs with an extensive command syntax, any other method of parsing would be major work. > 4. The ability to change the command syntax externally of the program > violates the autonomy of the tool. If I want to change the syntax, > then I'll change the code. The idea of giving an end user or > administrator the ability to change how tools interact "on the fly" > (as it were), gives me the willies. This is just an approach that > begs for endless debugging opportunities. Seems to me the principles of user interface design expressly distinguish between program functionality and command syntax. In any case, experience with this implementation has shown it not to be a problem. Users have no particular desire to confuse themselves by messing with command syntax -- even those who realise it's possible. And it's sufficiently non-trivial that those who know how to do it generally realise the consequences. > The only thing that I see of value is that the shell doesn't have to > load the image to know that there is a problem with the command > syntax. It a pretty trivial advantage, really (surprise :-). > A compromise would be be that the shell may *optionally* have a command > prototype in some shared memory hash table; but if the command is not in > the list, you let it go by. I would also want to be able to turn this > "feature" off and on at will. Thus, prototypes could be defined in > /etc/rc (or wherever), such as: > > proto rm 'fr' '(file ...)' Interesting... > Where the first argument is (of course) the command, the second argument > is the flags (with getopt() compatability) and folowed by a syntax > description of some sort. Some syntax handling (such as using rm to > remove a directory without the -r switch) should still be handled by > the tool in question. > > I suppose that you could even go one step further, and define usage strings > for mistyped commands as well: > > usage rm 'rm [-fr] file ...' > > So that if the novice user would enter: > > $ rm > sh: rm: missing filename in argument 1 > Usage: rm [-fr] file ... > > This is all nice and wonderful, but again, I had better have a way to > turn all of this nonsense off, such as: > > $ shutup > > Whaddaya think? > -- > Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation I think it's a good idea. Worth building on. And I very much agree with your point about such a facility being optional. A tool one can't avoid using is a straitjacket -- kinda like Pascal :-^). Tools will be used if they are worthwhile. -- /kenw Ken Wallewein A L B E R T A kenw@noah.arc.ab.ca R E S E A R C H (403)297-2660 C O U N C I L