3 ms·

Another interesting thing about Windows CMD：for most of internal commands, you can omit the space between the command and switch that starts with a slash (a com

Another interesting thing about Windows CMD：for most of internal commands, you can omit the space between the command and switch that starts with a slash (a common thing in Windows). E.g. the following two are the same: ipconfig/all ipconfig /all I always wonder how exactly this is implemented (and why?!). Edit: oh, another more famous example is the equivalence of cd.. cd .. And I have to admit I still do `ls..` from time to time, since I used Windows first (and most).

mrjin 3y ago
I guess only M$ can answer such question. My best guess would be that slashes are not allowed in file names and thus can be treated as delimiter and thus the cmd can actually try to interpret the part before the slash as the command and execute it.
JdeBP 3y ago
As the author of a CMD replacement long ago, I remember Rex Conn's comments on how the command-line parser of COMMAND (and hence CMD) was quite arbitrary. What was implemented, though, was a set of characters that acted as separators between the command name and the rest of the command tail. To many people's surprise in years gone by, this included not just whitespace but things like forward slashes and equals signs and commas. If memory serves, there was even an undocumented NLSFUNC table for looking them up, although my memory might be mis-serving me here. So one could, for example, treat the COMMAND command line as if it were CONFIG.SYS and do SOMETHING=ARGUMENTS, which was particularly useful for the built-in PATH and DPATH commands. MS/PC/DR-DOS, and indeed OS/2, programs were passed not a set of arguments but a single command tail, limited to 126 characters on MS/PC/DR-DOS and limited to 64KiB for the whole command-tail(s)-plus-environment-strings on OS/2. (It was the runtime libraries of programs written in programming languages such as C that did of all of the fakery that pretended that there was an argv[], and notably there were slight disagreements between Microsoft, Borland, and Watcom on the wild edge cases.) Usually, the first character of this command tail was the whitespace separator character that got entered by the user. But it didn't have to be.
- deleted 3y ago
  [deleted]

mrjin 3y ago

I guess only M$ can answer such question. My best guess would be that slashes are not allowed in file names and thus can be treated as delimiter and thus the cmd can actually try to interpret the part before the slash as the command and execute it.

JdeBP 3y ago

As the author of a CMD replacement long ago, I remember Rex Conn's comments on how the command-line parser of COMMAND (and hence CMD) was quite arbitrary. What was implemented, though, was a set of characters that acted as separators between the command name and the rest of the command tail. To many people's surprise in years gone by, this included not just whitespace but things like forward slashes and equals signs and commas. If memory serves, there was even an undocumented NLSFUNC table for looking them up, although my memory might be mis-serving me here. So one could, for example, treat the COMMAND command line as if it were CONFIG.SYS and do SOMETHING=ARGUMENTS, which was particularly useful for the built-in PATH and DPATH commands. MS/PC/DR-DOS, and indeed OS/2, programs were passed not a set of arguments but a single command tail, limited to 126 characters on MS/PC/DR-DOS and limited to 64KiB for the whole command-tail(s)-plus-environment-strings on OS/2. (It was the runtime libraries of programs written in programming languages such as C that did of all of the fakery that pretended that there was an argv[], and notably there were slight disagreements between Microsoft, Borland, and Watcom on the wild edge cases.) Usually, the first character of this command tail was the whitespace separator character that got entered by the user. But it didn't have to be.

deleted 3y ago
[deleted]