butenhof@clt.dec.com (07/10/86)
>>> >>>Most Unix programs will print out a line or so of "usage" diagnostics if you >>>invoke them with bogus arguments. Do VMS programs do this? >>> >> >>No. VMS programs will not let you invoke them with bogus arguments. Since >>the arguments are parsed by DCL before the program is invoked, if you give >>too many parameters or an unknown switch DCL will reject it with an error >>message that points out the specific problem. > > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! This is getting absurdly nested, but as the old saying (almost) goes, "the context must be kept" (I know, it really doesn't, but then, we all make up old sayings every day, right). VMS has a simple command language specifically for describing command lines. You describe the command verb, the image name or routine name which implements it, the number and data type of parameters, qualifiers, and qualifier values. This description is a separate module of a program. For "real" commands, it's generally compiled directly into the master system command table image (SYS$SHARE:DCLTABLES.EXE), where DCL will look by default for commands. However, you can also compile that description file, using the SET COMMAND/OBJECT command, into a standard .OBJ file, which can be linked in with the program. You then get the command line you wish to parse (you can get it from DCL by LIB$GET_FOREIGN, or by whatever other means you wish), and call the CLI$DCL_PARSE service to parse it according to the command description linked into the program. The program uses simple services like CLI$PRESENT to ask if a qualifier or parameter was specified, or CLI$GET_VALUE to get the value. Each parameter and qualifier has a name by which it's known to the program (like a standard variable name), passed as a string to the CLI$ routine. This means that the command description can be radically modified (for example, translated), and the program itself doesn't have to be modified at all. Because DCL has an exact description of the syntax of the command, it can issue reasonable diagnostic messages (although in many cases it *could* do better than it *does*). For example... Verb Foobar Image FOOBAR Parameter P1, Label=F1, Prompt="Which Foo", Value (Required, Type=$INFILE) Qualifier Bar, Label=F2, Value (List) describes a command FOOBAR which is implemented by the program FOOBAR (on SYS$SYSTEM, by default), with an input file parameter P1 (known to the program by the label "F1" and to the user by the prompt "Which Foo"), which the user is required to specify; and an optional qualifier BAR (/BAR in user syntax), which the program refers to as F2. /BAR can take a list of values, of ordinary string type. E.g.: FOOBAR/BAR=(A,B,C,HIPPOPOTOMUS) SOME-FILE.FILE-TYPE You can specify things like whether a qualifier affects only the particular parameter it follows, or the entire command; whether certain parameter and/or qualifier combinations are mutually exclusive ("DISALLOW" statements), define keywords which can be used as parameters (and DCL will resolve abbreviations and report ambiguities), and so forth. There's quite a lot of power and flexibility in the language. And yes, as I said (but to make it explicit), any Joe Blow program can use every bit of the capability of this interface with a very small amount of programming. Even non-privileged users (it takes privilege to put a command in DCLTABLES.EXE, obviously, since that's a shared resource) can use it... either by linking the command description .OBJ file into the image and using the program as a "foreign command" (defining a DCL symbol to "$image-name"), or by doing a SET COMMAND to compile the description and insert it in the user's memory image of DCLTABLES... which makes it just like a "real" command within the user's process. /dave Dave Butenhof ZKO2-3/K06 Digital Equipment Corp. 110 Spitbrook Road Nashua NH 03062 clt::butenhof butenhof%clt.DEC@decwrl.ARPA {allegra,shasta,decvax}!decwrl!dec-rhea!dec-clt!butenhof Any resemblance between the opinions expressed in this article and any actual opinions, living or dead, is strictly coincidental and in no way binding upon either myself or upon Digital Equipment Corporation, much less upon reality itself. ``Any sufficiently advanced technology is indistinguishable from a rigged demo.''