home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 262,392 of 264,096   
   bill to Mark Berryman   
   Re: Local Versus Global Command Options   
   17 Feb 25 16:09:40   
   
   From: bill.gunshannon@gmail.com   
      
   On 2/17/2025 2:02 PM, Mark Berryman wrote:   
   > On 2/16/25 5:43 PM, Lawrence D'Oliveiro wrote:   
   >> On Sun, 16 Feb 2025 15:52:23 -0700, Mark Berryman wrote:   
   >>   
   >>> On *nix systems, the shell parses the command line into an array of   
   >>> strings using unquoted spaces as the separator which is then passed to   
   >>> the created process.   
   >>   
   >> If you don’t go through a shell, then you pass an array of already-   
   >> separated words and you don’t have to worry about shell specials.   
   >>   
   >>> On VMS, the crtl does the same parsing which means the program still   
   >>> sees an array of strings the same as on a *nix system.   
   >>   
   >> 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.   
   >   
   > 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=.pdf .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.   
   >   
   >>   
   >> So now, how do you invoke program X directly from your own program Y,   
   >> without going through DCL? For consistency, you have to mimic all the   
   >> same   
   >> misbehaviour of DCL to get the command line in the right format. If you   
   >> don’t want to do that, then you need some option to tell program X to   
   >> bypass all that special processing, and just accept the command line as   
   >> is. So it needs to distinguish between two ways of being invoked:   
   >> directly   
   >> or via DCL!   
   >   
   > Wrong again. There are a number of ways to invoke a program without   
   > going through DCL.  Since you seem to be a Linux fan, look up the   
   > various exec functions for starters.  (Note, there are other ways).   
   >   
   >>   
   >>> If I choose to use DCL, DCL does all of the parsing for me and the   
   >>> nature of the command-line is irrelevant.   
   >>   
   >> If you don’t use DCL, then how do you invoke a program that expects   
   >> DCL to   
   >> parse its command line for it? What happens to all of Arne’s lovingly-   
   >> crafted .CLD files?   
   >   
   > You apparently know as little about VMS as you do programming in   
   > general.  The Docs are online.  Go read them.  They will answer your   
   > questions.   
   >   
      
   Which is why people need to stop feeding the troll!!!!   
      
   >>   
   >>> Programs on DEC OSes can invoke other programs directly and   
   >>> have been able to at least since the days of the PDP-11 ...   
   >>   
   >> Yes, and there have been quite a few pitfalls with that, as I mentioned   
   >> above. Windows suffers from the same drawback, and this has even led to   
   >> security holes with Windows programs.   
   >   
   > Hmmm, first you tout that invoking programs directly eliminates pitfalls   
   > then you claim that doing so causes them.  So, which is it?   
   >   
   > Mark Berryman   
   >   
   >   
   >   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca