Article 133386 of comp.os.vms: Path: nntpd.lkg.dec.com!crl.dec.com!crl.dec.com!caen!reeve.research.aa.wl.com!decwrl!lll-winken.llnl.gov!uwm.edu!homer.alpha.net!mvb.saic.com!info-vax From: "GWDGV1::MOELLER" Newsgroups: comp.os.vms Subject: Re: We've got P1 to P8 arguments, so how about a P0 ? Message-ID: <64385969@MVB.SAIC.COM> Date: Mon, 6 Nov 1995 15:04:00 +0100 Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Lines: 56 Indeed want to second the admonition from Ken : >[...] > Finally I'd like to note that some well known, freely available > utilities written by someone I don't know but do respect and am > grateful to, :-) go to a good deal of trouble trying to figure out > whether the utility was activated via a DCL verb, a foreign command, > the RUN command, or MCR. And all using undocumented SYS$CLI calls. > Please don't do this. It's not needed, is subject to error, and > probably takes longer to accomplish than just reparsing the command > line! Don't you just _hate_ it when a program that is "supposed" to be invoked via a foreign command, gets confused when you dare invoke it via MCR ?! Here's my list of methods available for getting at most of the command line: LIB$GET_FOREIGN() gets the parameter list (i.e. the command line excluding the command or executable file name). Highly recommended. (*) CLI$GET_VALUE("$LINE") gets all of the command line, including the "RUN" or "MCR" verbs (if applicable). In case of a foreign command, the 1st token is the program name (_not_ the symbol). No .CLD required for this item. Better don't try parsing the output ... CLI$GET_VALUE("$VERB") gets the "command verb" (may be "RUN" or "MCR"), _unless_ the program was invoked by a foreign command. No .CLD required for this item. Without .CLD environment, currently not useful (_ought_ to return failure with foreign command, but instead returns the last verb seen by DCL). SYS$CLI(...CLI$K_GETCMD...) [as recently demonstrated by D.Murphy] gets the command line with the first token stripped. Most confusing (in the "MCR" case)! (*) If you need something like C argv[0], it's probably best to pick up the program's name from LIB$GETJPI(...jpi$_imagname...); there's no means anyway to get at the symbol that was used to invoke a foreign command. Note that the recall buffer has just interactive (terminal) input, in general _not_ the command that invoked the image (which may be part of a command procedure). As regards Fred Bach's "P0" meaning "unparsed command line", there's indeed no way to get at this; traditionally, the DCL parser does most kinds of substitution (including substituting for a foreign command name) prior to recording anything about its input. Wolfgang J. Moeller, Tel. +49 551 2011516 or -510, moeller@gwdgv1.dnet.gwdg.de GWDG, D-37077 Goettingen, F.R.Germany PSI%(0262)45050859008::MOELLER Disclaimer: No claim intended! | moeller@decus.decus.de w.moeller@ieee.org