[Info-vax] Command Line Versus Command Line

[Michael S]

On Thu, 23 May 2024 18:37:35 +0100
chrisq <devzero at nospam.com> wrote:

> On 5/23/24 17:41, Arne Vajhøj wrote:
> > On 5/23/2024 12:02 PM, Michael S wrote:  
> >> On Thu, 23 May 2024 09:28:16 -0400
> >> Arne Vajhøj <arne at vajhoej.dk> wrote:  
> >>> On 5/23/2024 6:19 AM, Scott Dorsey wrote:  
> >>>> Lawrence D'Oliveiro  <ldo at nz.invalid> wrote:  
> >>>>> And just to add to the fun, CP/M, MS-DOS and then Windows NT all
> >>>>> copied the basic DEC-style command line architecture, while
> >>>>> neglecting the crucial part of a built-in command parser to
> >>>>> handle more sophisticated syntax. So Microsoft’s recent
> >>>>> rediscovery that “the command line is cool” remains hampered by
> >>>>> this brain-dead underlying architecture.  
> >>>>
> >>>> To give them credit, Microsoft finally realized that command.com
> >>>> was hopeless and started from first principles with Powershell.
> >>>> Powershell is easily as good as anything DEC had in 1974 and as
> >>>> such is a huge advance for the desktop.  
> >>>
> >>> Just so that everyone know the history:
> >>>
> >>> command.com - 1980
> >>> cmd.exe - 1987 (backwards compatible with command.com, but
> >>> significantly extended functionality, often via obscure syntax
> >>> though)  
> >>
> >> Thanks.
> >> Until reading your post I didn't realize that cmd.exe existed
> >> before Nt 3.1 (1993).
> >> Personally I often feel that cmd.exe is an improvement on it's
> >> successor.  
> >>> Windows Script Host / VBScript - 1995 (not interactive, scripts
> >>> only, but very powerful via WMI)
> >>> PowerShell - 2006
> >>>
> >>> Not super new.  
> >   
> >> BTW, I tried to figure out what "command line architecture"
> >> Lawrence is talking about, but didn't quite succeed.  
> > 
> > Neither did I.
> >   
> >> As far as Win32 CreateProcess() function is concerned, command line
> >> is just a string. If caller omits applicationName parameter then
> >> system does small amount of parsing to find application name in
> >> command line. But when caller provides applicationName parameter,
> >> which is a most logical thing to do in any
> >> non-interactive/non-shell scenario, then OS does not care at all
> >> about content of command line. In both cases OS does not modify
> >> command line and passes it to child process as is.  
> > 
> > The concept is pretty common.
> > 
> > VMS LIB$SPAWN and C system also use full command line.
> >   
> >> So, the only difference between *nix and Windows is array of
> >> ASCIIZ strings (today, of UTF8 strings) vs single, possibly very
> >> long, null-terminated ASCII or UTF16 string.  
> > 
> > In most practical usages it does not matter at all.
> > 
> > But it can matter if one needs to construct a single command
> > line from multiple arguments and those arguments contain
> > spaces or shell operators.
> > 
> > Example:
> >    https://nvd.nist.gov/vuln/detail/CVE-2024-24576
> > 
> > Arne
> > 
> >   
> 
> Unix shell just uses single quotes to enclose spaced arguments, which
> are then removed by the shell, before storing the argument as pointer
> to a null terminated array of char. Neat, clean and simple.
> 

Moving pointers between address spaces is never very simple. Moving
variable-length arrays of pointers adds another level of complexity on
top of it.
Not a rocket science, but not as simple as copying a single monolithic
string.

> At parser level, there has to be some agreed token(s) to delimit the
> command line arguments and spaces or tabs are still the simplest way
> to handle that. Things like spaces in filenames are a bit of an
> abomination, but thank uSoft for that. How would you handle it ?...
> 
> Chris
> 

Microsoft's own conventions are documented here:
https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170
They provide default parser
https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw
And, of course, they have it built-in in C start-up library code.

But when you have control over both parent and child processes, you do
not have to follow Microsoft's conventions if you prefer some different
way.