[Info-vax] Local Versus Global Command Options

[Arne Vajhøj]

On 2/17/2025 4:49 PM, Lawrence D'Oliveiro wrote:
> On Mon, 17 Feb 2025 12:02:37 -0700, Mark Berryman wrote:
>> On 2/16/25 5:43 PM, Lawrence D'Oliveiro wrote:
>>> Consider what happens: if you pass unquoted text to program X, DCL
>>> converts it to uppercase, and I think also normalizes multiple spaces
>>> to a single space. If you don’t want the text to be uppercased or
>>> space- normalized, you put it in pairs of double quotes. But then these
>>> double quotes also get passed as part of the command line. So the
>>> receiving program has to do some non-trivial parsing just to get simple
>>> literal text via the command line.
>>
>> So, so, so very wrong.  You are *way* behind the times.
>>
>> I *never* have to quote arguments when using programs that still use
>> *nix syntax on VMS.  My arguments' case is never changed.
> 
> Prove it. It seems to me what you are claiming would break backward
> compatibility with the way VMS used to work.
> 
>> Here is the entry point to any C program on VMS:
>>
>>    int main (int argc, char *argv[], char *envp[]);
>>
>> See?  Argument passing works the same on VMS as it does on *nix, as
>> described above.
>>
>> Let's see, what's a good example?  Ah, here's one:
>>
>> $ gs -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr
>> -sOutputFile=<something>.pdf <something>.ps
>>
>> Again, see?  No quoting.  No case conversion.  Ghostscript sees the
>> command exactly as I typed it and I typed it exactly as I would on a
>> *nix system.
> 
> Can you show us a simple C program that just prints out its command
> arguments, and how it responds to some sample command lines?

Why would we do that?

Last time you came with those claims I posted (23-May-2024)
a rather extensive demo with CLI, foreign command, hybrid, C
and DCL with both /parse=ext and /parse=trad.

Apparently you did not read it. Which is fine, but don't expect
anybody to redo the work when you did not read it the first time.

Arne