3 ms·

Some reasons why CMD.EXE is so bad: (1) COMMAND.COM cut a lot of corners, in significant part due to being written in assembly and designed to run on machines

Some reasons why CMD.EXE is so bad: (1) COMMAND.COM cut a lot of corners, in significant part due to being written in assembly and designed to run on machines with very low memory (DOS 1.0 would run on machines with only 32KB of RAM) (2) Backward compatibility meant a lot of the questionable decisions in (1) had to be maintained (3) At some point Microsoft stopped investing in it, and didn't do anything further to add new features or file off more rough edges I think (1) and (2) were kind of inevitable, but (3) is a decision Microsoft has made much more recently I wish they'd open-source CMD.EXE and start accepting PRs for it – I think some of the worst things about it (e.g. the "Terminate batch job (Y/N)?" prompt which is impossible to turn off without patching the executable) would get fixed. But I doubt they'll do that because they just want people to focus on PowerShell instead–and before PowerShell, it was the same thing for VBScript

WorldMaker 3y ago
At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point. Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE. [0] https://github.com/microsoft/terminal/tree/main/src/host https://github.com/microsoft/terminal/tree/main/src/host
- skissane 3y ago
  PowerShell is rather heavy and takes a lot longer to start than CMD.EXE does I think there are plenty of little annoyances in CMD.EXE which could be fixed. That prompt I mentioned is the most obvious one, but I'm sure there are more.
chasil 3y ago
Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc. Neither Korn/pdksh nor CMD.EXE can meet such a requirement. DOS batch compatibility could easily be met with a secondary command shell. NT's primary command shell could have reworked AWK's grammar into an interactive shell. It's a shame that the NT command shell did not recieve the attention that it deserved. DCL would have been preferable (if you like FORTRAN).
- skissane 3y ago
  > Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc There are plenty of parser generators other than yacc, many of which accept different types of grammars from LR (e.g. LL parsers, PEG parsers). I'm not sure why it should matter whether a command processor's grammar is LR or LL or whatever.
  - chasil 3y ago
    The POSIX shell (and its precursors and derivatives) are not LR-parsed languages, and they suffer from ambiguities and inconsistencies. The extent of the distrust is clear in the video and slides below. I don't know as much about the descent of the COMMAND.COM of MS-DOS with the influence of OS/2 into NT CMD.EXE, but I can say with certainty that it was no better. We needed something clean and maintainable, and we didn't get it. https://archive.fosdem.org/2018/schedule/event/code_parsing_posix_s_hell/ https://archive.fosdem.org/2018/schedule/event/code_parsing_...
    - skissane 3y ago
      The problem the slides are raising is that the POSIX shell's grammar is ad hoc: despite the POSIX standard containing an LR yacc grammar, it is annotated with English-language rules which violate the LR formalism. But not being LR-parsed in particular seems like a red herring – if it had been designed to be cleanly LL-parsed, I don't think anyone would be complaining.
      - chasil 3y ago
        > The problem the slides are raising is that the POSIX shell's grammar is ad hoc... ...and that's the point. A shell language with no inconsistencies or ambiguities is what we needed, and we didn't get it. A language with a formal yacc grammar would have helped us get it. Neither the POSIX shell nor CMD.EXE are ever going to meet such a requirement. I don't know if DCL was clean enough to have a yacc grammar. If it was, then it would have been a better choice. I don't know why you are defending such a precept when the weaknesses are so very well known. EDIT: A yacc grammar might be preferred as yacc itself is part of POSIX.2, assuring many implementations. You can find lex and yacc here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ However, had any formal grammar been used, it would have been far better than what we have now.

WorldMaker 3y ago

At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point. Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE. [0] https://github.com/microsoft/terminal/tree/main/src/host https://github.com/microsoft/terminal/tree/main/src/host

skissane 3y ago
PowerShell is rather heavy and takes a lot longer to start than CMD.EXE does I think there are plenty of little annoyances in CMD.EXE which could be fixed. That prompt I mentioned is the most obvious one, but I'm sure there are more.

chasil 3y ago

Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc. Neither Korn/pdksh nor CMD.EXE can meet such a requirement. DOS batch compatibility could easily be met with a secondary command shell. NT's primary command shell could have reworked AWK's grammar into an interactive shell. It's a shame that the NT command shell did not recieve the attention that it deserved. DCL would have been preferable (if you like FORTRAN).

skissane 3y ago
> Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc There are plenty of parser generators other than yacc, many of which accept different types of grammars from LR (e.g. LL parsers, PEG parsers). I'm not sure why it should matter whether a command processor's grammar is LR or LL or whatever.
- chasil 3y ago
  The POSIX shell (and its precursors and derivatives) are not LR-parsed languages, and they suffer from ambiguities and inconsistencies. The extent of the distrust is clear in the video and slides below. I don't know as much about the descent of the COMMAND.COM of MS-DOS with the influence of OS/2 into NT CMD.EXE, but I can say with certainty that it was no better. We needed something clean and maintainable, and we didn't get it. https://archive.fosdem.org/2018/schedule/event/code_parsing_posix_s_hell/ https://archive.fosdem.org/2018/schedule/event/code_parsing_...
  - skissane 3y ago
    The problem the slides are raising is that the POSIX shell's grammar is ad hoc: despite the POSIX standard containing an LR yacc grammar, it is annotated with English-language rules which violate the LR formalism. But not being LR-parsed in particular seems like a red herring – if it had been designed to be cleanly LL-parsed, I don't think anyone would be complaining.
    - chasil 3y ago
      > The problem the slides are raising is that the POSIX shell's grammar is ad hoc... ...and that's the point. A shell language with no inconsistencies or ambiguities is what we needed, and we didn't get it. A language with a formal yacc grammar would have helped us get it. Neither the POSIX shell nor CMD.EXE are ever going to meet such a requirement. I don't know if DCL was clean enough to have a yacc grammar. If it was, then it would have been a better choice. I don't know why you are defending such a precept when the weaknesses are so very well known. EDIT: A yacc grammar might be preferred as yacc itself is part of POSIX.2, assuring many implementations. You can find lex and yacc here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ However, had any formal grammar been used, it would have been far better than what we have now.