Re: forgetting my DCL: what am I missing?

Phillip Helbig---remove CLOTHES to reply wrote:
> In article <dr37kt$nt1$1@xxxxxxxxxxxxxxxx>, Ken Fairfield
> <my.full.name@xxxxxxxxx> writes:
>
> > Here's a little DCL trick that will solve your problem.
> > Change the symbol definition(s) to read as follows:
> >
> > $ WWW_NEWTRACE == "''priverequest' 931 NEWTRACE'"
>
> David Jones (who wrote the OSU server) offered the same suggesting on
> the mailing list for the server.
>
> > Note the trailing apostrophe just prior to the closing quotation
> > mark. That's the key. Here's a demontration:
>
> > I admit to not knowing what "feature" or rule of DCL manages to
> > accomplish this feat, but I do know I have used it more than once
> > in the past.
>
> Apparently, this trick will not only get rid of the implied space (why
> is that there in the first place) but also get rid of real space in the
> command line.

Whatever it is it has something to do with the fact that foreign
command substitution happens in phase 2 of DCL command processing --
namely, command parsing. Apparently, DCL decides that the result of
substituting for WWW_NEWTRACE is the command verb (plus any
"parameters"). Anything following it (in this case, the /11 part) is
simply treated as completely separate stuff. Putting a space there is
consistent with that. Apparently, someone at DEC wanted to do what you
wanted to do and sneaked in the apostrophe trick. The apostrophe
apparently tells DCL to append the first token following the foreign
command to the last token in the foreign command definition.

It is also said that DCL does not parse such commands. I think this
really means that the stuff following the .exe file-spec is not
*interpreted*, especially slashes as qualifier indicators. And it is up
to the program to gather this stuff and parse and interpret it.

>----o----<

I don't know of any doucmentation that can explain this apostrophe
trick. The apostrophe is not known to the command interpreter until the
foreign command is substituted for -- and that happens in phase 2 --
whereas apostrophes are documented only for phase 1.

BTW: One can also ask why your application can't handle the extra
space! Especially since the /11 starts with a slash. :-)

>
> > And of course, as others have noted, the reason PRIVREQUEST is
> > giving you this problem is because it is *not* using DCL to parse
> > the command line. Otherwise, a space before a qualifier wouldn't
> > matter. One of my pet peeves is "imitation" DCL command lines...

So why doesn't the program ignore the space?

>
> Yes. I prefer a real CLD (which doesn't have to mess with the DCL
> tables; one can compile it into the foreign command). In this case, my
> suspicion is that, since the server was written with VMS in mind (and
> originally for VMS), a VMS "look and feel" was desired but, since it
> apparently also runs on Digital Unix (wasn't there also DECnet available
> for Digital Unix (the server can run without it but runs better with
> it)), code was needed which would run on both.

.