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: 3, Interesting) by martyb on Friday May 29 2020, @02:05PM (2 children)
I'm coming from using MKS Toolkit [wikipedia.org] dating back to the ~1990. It provided over 170 Unix commands implemented as .exe files. There was a version of the toolkit that ran on DOS/Windows and another on OS/2.
Later, I came upon UnxUtils [sourceforge.net] which provided ~130 Unix commands that were more up-to-date than the MKS utilities.
Along the way, I would run into issues and look around some more for alternatives. This led me to finding: GnuWin32 [sourceforge.net], Gow (GNU on Windows) [github.com], and ezwinports [sourceforge.net].
Somewhere along the way, I kept hearing glowing reports about cygwin. So I downloaded it and installed. It screwed up my PC royally, uninstall was not clean, and I had to resort to a LOT of regedit hacking to get things working again. That's a couple weeks of my life I'll never get back.
Along the way, I had jobs where I wrote scripts in sh, csh, and bash on various flavors of Unix.
Given these scripts were performant in pre-Pentium days, I expect they would be even more so with today's much more powerful processors and abundant RAM.
So, I'm leaning towards bash for ease of transfer to a Linux platform, but have seen that Python has a lot of support with add-on libraries(if that's the term) and I have no desire to reinvent the wheel, either. Hmmm, I suppose I could port what I have to bash... and in parallel investigate Python for implementing new functionality.
Thanks for the help! ;)
Wit is intellect, dancing.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @02:59PM
I used MKS Toolkit as well, back in the day.
I hadn't heard of UnxUtils or ezwinports. Thanks!
I adopted Cygwin when it was still called Cygnus Tools [wikipedia.org]. As such, while I did use some GNUWin32/GOW tools (I still prefer their Emacs to the Cygwin port),
Cygwin isn't a toolkit per se, rather it's a POSIX layer implemented as a dll, so cygwin1.dll must be present to support the packages requiring it.
There was a period (not sure when you had problems) when the Cygwin install process wasn't very clean, and I had my own share of issues with it.
However, I never had to resort to editing the registry. Thankfully, things have improved significantly in that area.
At this point, the advantages of Cygwin *for me* are the broad (much broader than GOW or any other toolkit) set of ported packages (a little less than 5000, IIRC) and my long familiarity with it.
That said, there are plenty of other use cases where other toolkits would be quite useful. Many folks just want a basic set (or just a few, or just one) of unix commands. And since all cygwin tools *require* the cygwin1.dll POSIX layer, that could add a little complexity with distribution.
(Score: 2) by Revek on Saturday May 30 2020, @12:43PM
I did try this a long time ago and it was buggy as hell. Guess I should revisit it.
This page was generated by a Swarm of Roaming Elephants