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: 4, Interesting) by meustrus on Friday May 29 2020, @02:38PM (7 children)
If you're porting your scripts, please don't target bash. It has a lot of non-portable extensions, and people are quite fond of preferring the extensions over the portable syntax.
A better lowest common denominator is Almquist shell (ash or dash). Anything that works in Almquist should work fine in Bash. The same cannot be said in the opposite direction.
Targeting Almquist will help ensure your scripts are portable beyond just thick Linux systems and also work in BSD and embedded Linux.
Also try to be aware of GNU extensions in utilities like sed and awk. Again, they can be useful, but they are not portable to BSD or OS X, which tend to be only strictly POSIX-compatible.
Scripting for Almquist is not exactly the easiest thing, but if you're used to Cmd.exe's quirks, Almquist's should be a piece of cake. If it gets annoying though, you may as well go for pretty much any interpretable language rather than bash. Python works, as would Ruby or Go. You could also technically target Node.JS, PHP, or Perl if you hate yourself.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(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.
(Score: 3, Informative) by wirelessduck on Sunday May 31 2020, @02:20PM (2 children)
ShellCheck [shellcheck.net] is a lifesaver when trying to detect bashisms in your portable shell scripts.
(Score: 0) by Anonymous Coward on Sunday May 31 2020, @08:05PM (1 child)
I second that. Just make sure the shebang is correct. I've seen one too many people wonder why their script isn't portable when their shebang is explicitly set to bash. Also, even when called with sh as arg[0], bash still implements some common bashisms.
(Score: 2) by meustrus on Monday June 01 2020, @04:31PM
Well yeah. Bash is a GNU project, and carries some ideology. GNU would like to infect everything with GPL, so their use of Microsoft's "Embrace, Extend, Extinguish" strategy is not exactly surprising.
Which is not to say I dislike GNU or GPL. I wish companies like Apple would give up their fight and accept it. But on a technical level, adding non-standard features to standard tools and making it unclear which features are non-standard is pretty slimy in my opinion. And in this case, it has completely failed to get anybody to accept GPL.
Free software is great. Well-maintained free software is greater. Universal standards with well-maintained free implementations is the greatest.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?