Microsoft senior program manager Rich Turner took to Twitter in recent days to remind everyone that it really is time to move on from Windows' ancient command processor, cmd.exe.
"Cmd is in maintenance mode," said [twitter.com] the Windows Terminal and Windows Subsystem for Linux pusher, "it should not be used for interactive shell work."
[...] To be fair, cmd has been a little whiffy for a while now. As the original default command line interpreter for the Windows NT (and OS/2) era, it has its roots in the old COMMAND.COM days of DOS and Windows 95, and provided a way for admins to move their ageing batch files and scripts into a brighter, DOS-free world.
[...] Microsoft has long punted an alternative to users in the form of the vastly more capable PowerShell, which appeared in Windows-only form back in 2006 before going cross-platform and open source 10 years later (briefly acquiring the suffix "Core" as it did so).
Many organisations, however, have plenty of legacy cmd scripts still running behind the scenes. The engine running those scripts is now in "maintenance mode", meaning that something pretty major would have to go wrong before anyone in Redmond goes tinkering. Every time a change is made, explained Turner [twitter.com], "something critical breaks".
[...] Turner's pointer to PowerShell is not without its own problems. While PowerShell 7 may be the future, what is currently lurking in the big box of Windows is version 5.1, which, like cmd, is in maintenance mode and has received only the odd fix or three as it waited for the Core incarnation to get closer to parity.
Lee, a 20-year Microsoft veteran and principal software engineer manager, chimed in [twitter.com] that the gang "can't update inbox to PS7 until we reconcile the LTS support gap between .NET and Windows".
Spaghetti code and structured code can be written in [nearly any] language. I've now constructed well over 3,000 .BAT/.CMD files — some dating back to the early 1990s — which I still use to this day. I'll grant there are some quick-and-dirty one-offs in the mix, but the vast majority employ structured programming, have a modification history, are fully-commented, and have help (with examples) available from the command line.
I'm looking to port them to run on Linux (Ubuntu/Mate). Many of them make use of Windows ports of Unix utilities like gawk, sed, wc, date, ls and a smattering of others as the need arose.
Context: I've been writing "batch" programs (DCL, EXEC, REXX, TECO, Tcl/Tk, Elisp, sh, csh, bash, Perl, etc.) starting in the the 1980s. It seemed that each operating system had its own command language, so I'd just learn and make use of whatever was available on that system.
Just for least-common-denominator's sake, I'm tempted to port them to bash. I have some experience with it (and other shells such as sh and csh going way back). bash also has the advantage of being written when processors were much slower and memory was severely limited. So performance should be excellent.
On the other hand, Python is popular and thereby has lots of on-line support available.
What has been your experience?