SoylentNews is people
SoylentNews
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 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, "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 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?
(Score: 2) by martyb on Friday May 29 2020, @06:31PM (3 children)
Thanks for the cautions and the pointer to ash/dash.
I have a couple things working in my favor. My .CMD files are generally well-commented often to the point of having snippets of actual input/output as I munge things along the way. Also, I will have the benefit of having ported many of these to different versions of DOS, OS/2, and Windows along the way and on physically different systems as I upgraded my computer/OS. For example, my upgrade from Windows/XP to Win7/Pro x64 was almost painless. Copied all the files over. Set some environment variables (env vars). Cross my fingers. Try stuff. It pretty much all worked, and when it didn't, it was usually readily apparent where things were going wrong.
Although I'll be the first to admit that it looks like an ugly hack, I have a bunch of .CMD files that set an env var to a particular directory for some task, like accessing my SoylentNews tools. In this case, to set the env var, I had soydir.cmd, and to make it convenient to get to that location, gosoy.cmd which calls soydir.cmd, then does a CD to the drive and directory specified in the soydir env var, and then updates the CMD.exe window title the with current location. If I wanted, I could move that whole SoylentNews tree to, say, a different drive and just by updating soydir.cmd everything would just work with the new location. All of these little tools would live in my utility directory, which was pointed to by the util env var which was set in .autorun.cmd and, also, in Control Panel / Advanced System Settings / System Properties / Advanced tab / Environment Variables.
Wit is intellect, dancing.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @09:35PM (1 child)
For shortcuts like that, I keep a ~/.config/sh/env.sh, func.sh and alias.sh, sourced in my .profile. If it's inconvenient for anything to be aliases or functions (usually because of context), .local/bin holds those. You could share environmental variables with some logic to use the correct methods for setting them, but that's probably not worth the effort.
(Score: 2) by martyb on Wednesday June 03 2020, @08:32PM
Thanks for that!
Like I said, it's ugly. Grew organically from seeing env vars like ROOTDIR and TMPDIR. I eventually wrote a short program "goenv" which would take the value of an env var, CD to that drive and dir t make it current, and update the CMD window title with the new current location.
Now, it is so easy to just set up some new location for some project, have everything key off an env var so all the tools "know" where everything is located, and go from there. Moving things someplace else is trivial.
I've toyed with the idea of a central program which handles the setting of all env vars on in a single file... but this works, and that would take work and time that I do not have in great excess, so it's been easier to just keep doing what I've been doing.
That said, I'll certainly keep this in mind when porting things over to Linux!
Thanks again!
Wit is intellect, dancing.
(Score: 2) by Common Joe on Sunday May 31 2020, @09:05AM
If you're looking for the "run anywhere", bash (or I guess ash / dash; I'm not familiar with those shells) are the way to go.
However, I suggest looking at fish shell [fishshell.com]. Some (most?) distros have it in their package repository and I like it a lot. The syntax is a lot less cryptic than bash and therefore more readable.