[Info-vax] Command Line Versus Command Line

[Dan Cross]

In article <20240523223853.00007d91 at yahoo.com>,
Michael S  <already5chosen at yahoo.com> wrote:
>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
>> 
>> 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.

I'm not sure how that's particularly relevant; moving argument
strings between address spaces in Unix is handled by the kernel,
not userspace programs (which call a library routine to invoke
the relevant system call).  The above quote was about
tokenization, which in Unix shells tends to be very simple.

	- Dan C.