tli@usc-oberon.UUCP (Tony Li) (07/09/86)
In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: > >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)! Random isn't quite clear on this. The program itself doesn't ever need to look at the command line. Instead, DCL does all of the parsing of the command. For an applications programmer, you deal with the "messy" interface requirements by telling DCL what your command arguments should look like via a command definition file. Then, when you write your program, you can ask DCL what the arguments were. It's actually very clean and neat... It is standard, and it is the way that all of DEC's programs interface with DCL. It is definitely a first-class way to go. Yes, it is complicated. Yes, it provides more functionality than getopts(3). Yes, there is a way to bypass the whole mess and read the command line yourself (this, incidentaly, is the second-class way to go). Yes, it is standard. No, the command definition language is not all that messy. It's actually quite cute, and gets around a LOT of grunt programming. Don't flame me, I don't read my mail. -- Tony Li ;-) Usc Computer Science Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth Csnet: tli@usc-cse.csnet Arpa: tli@usc-ecl.arpa