Our great sponsors
-
Windows Terminal
The new Windows Terminal and the original Windows console host, all in the same place!
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
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
There are languages with perfectly clean grammars which can't be parsed by yacc because they aren't LALR(1).
I agree that a command processor should have a grammar that can be expressed in a well-known formalism, and its parser generated by a parser generator.
I agree that both POSIX shell and CMD.EXE are flawed because that isn't true.
What I'm disagreeing with, is that it is important that the grammar formalism be LALR(1) in particular, and that the parser generator be yacc in particular.
Suppose I have a Packrat parser generator. [0] And my command processor has a nice clean PEG grammar. And I use the Packrat parser generator to generate the parser of my command processor. That grammar quite possibly isn't LALR(1), and hence yacc in particular won't be able to generate a parser for it. But what's the problem with that? If it is a problem at all, it is a very different problem than the problem that CMD.EXE and POSIX shell have
[0] e.g. https://github.com/arithy/packcc