[Info-vax] Command Line Versus Command Line

[chrisq]

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.

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