Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!bria!mike Newsgroups: comp.arch Subject: Re: shell architecture (to glob or not to glob) Message-ID: <378@bria> Date: 21 Jan 91 00:05:53 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> Reply-To: uunet!bria!mike (Michael Stefanik) Organization: Briareus Corporation, Los Angeles, CA Lines: 83 In article skyler.arc.ab.ca!kenw (Ken Wallewein) writes: [ discussion about shell looking at the program to determine usage ] > Well, it might, if it were done that way. The implementation with which >I am familiar doesn't, and it works rather well. The syntax of the command >is described in a special "concise command language", which is compiled >into a library, and which the shell keeps in shared memory. > > This has a number of benefits, including _simplified_ software >development (because the syntax of the commands can be decoupled from the >code itself), flexibility (you can call the parser from within your program >if you want to), flexibility (you can change the command syntax without >changing the program -- you don't even need source!), efficiency (you don't >even bother to load the program if the command doesn't follow the required >syntax), and so on. 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 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. 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. 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. 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. 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 ...)' 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 UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."