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, Insightful) by chromas on Friday May 29 2020, @01:37AM (2 children)
My non-expert experience with PowerShell is it's ridiculously slow to initialize. A new PS window takes at least 5 seconds to show a prompt and running a script like chocolatey also takes a couple seconds before anything happens.
As far as I know, most major distros have Python installed by default so you should be fine if you decide to go with it. Fair warning though: if you start learning Python then you just might have to take over Bender duties in IRC :D
(Score: 0) by Anonymous Coward on Friday May 29 2020, @05:05AM
not been my experience back to poshv3 on Win 7.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @11:26AM
This has not been my experience with PS either. It has been very responsive, and compared to using Python scripts, it is even more responsive. I love Python, and have for many years, for automating and gluing things together, but since I finally decided to learn PS more deeply, I'm converting my Python scripts to PS. If you're not in a Windows environment, then PS is probably not gonna be your thing. But I'm primarily Windows (Desktops and Servers) so it's perfect. I have used PS Core on an Ubuntu system, but it's not ready for prime time yet.
Microsoft is requiring PS modules for all their applications/systems moving forward, and many vendors are now making PS modules for their software as well. It's made managing Active Directory, SQL Server instances, and even my network switches (via SSH) a lot easier and more automated. Not to mention it's actually not too bad at using APIs for things like managing Google GSuite. Powershell.org is also a friendly place to find answers to all your PS questions.
(Score: 5, Insightful) by datapharmer on Friday May 29 2020, @01:43AM (1 child)
The problem with powershell is they can’t leave the commands alone. For anything non-trivial even the Microsoft support site can’t keep up and often has outdated info and you can’t actually run the commands or scripts without having to go out and search for what replaces the thing you are trying to use. Command.com may be ancient and terribly basic, but most of the same commands I used in dis days still work reliably on windows 10. There is something to be said for that. I will say that (as nefarious as I’m sure it is) the subsystem for Linux is nice as I can just use bash and not worry about what windows 10 flavor of the week happens to be installed and what it supports or doesn’t.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @02:05PM
this is a weird take.
cmd.exe has many variations, and has changed along the way. it is more useful in Win10 than Win7, and so on back through time. cmd.exe is even more useful than the old command.com, which itself got commands changed every new DOS version.
sure there are things that seem easier in cmd-land. I'll admit that 99%of that 'ease is just muscle memory and familiarity.
but there are just way more things that are doable.
dir -recurse *.pdf | select fullname, lastwritetime | ogv
cmd.exe does not have anything at all like out-gridview. imo out-gridview is incredible.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @01:45AM
See CLING [github.com] - if it's good for CERN may be good enough for anyone.
(Score: 4, Insightful) by el_oscuro on Friday May 29 2020, @02:04AM (5 children)
Sure, it's syntax is so janky it would make a Unix admin cringe. But at least it doesn't change. Just like being able to drop into a bash shell after not seeing it for several years, the same is true with CMD.
I once made a liviing with CMD - running an enterprise with 200+ remote oracle services. Combined with a few NT resource tools like SCLIST.EXE, SRVANY.EXE, and RCMD.EXE, I basically had full Unix style remote admin shells, a real cron scheduler and rotatelog style logging - all with CMD. 20 years later, we still have critical production systems that use it.
BTW, CMD has an excellent man page with lots of detailed examples. I know it is totally obscure, but you can access this man page by typing "help" at a cmd prompt.
SoylentNews is Bacon! [nueskes.com]
(Score: 3, Interesting) by JoeMerchant on Friday May 29 2020, @02:13AM (3 children)
I'm really addicted to the bashy/cmd shell that installs with git on Windows... opens fast, has a fair amount of familiar commands that work, particularly (obviously) git related ones.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Friday May 29 2020, @03:12AM
sure....
(Score: 2) by meustrus on Friday May 29 2020, @02:26PM (1 child)
That's bash from MinGW. I'm a fan also. It's a bit hard to work without a proper package manager; choco and scoop together still don't provide everything an apt, yum, or brew provides.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by JoeMerchant on Friday May 29 2020, @05:48PM
You know, configuring systems - which packages to install, remove, special versions, build from source libraries, VirtualBox custom configurations - I do all that for our products. On my daily drivers, the closer to stock I can run, the happier I am.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Tuesday June 02 2020, @07:39PM
Been thinking this a lot lately.
What seemed to draw me to Linux back in the day was that it looked a bit like DOS on steroids.
Sure, the boot was a whole directory of files rather than autoexec.bat and config.sys, but in a general sense it behaved like DOS in that you had your boot sector that fired up your kernel that gave you a command line that could launch a GUI.
These days it feels like everything else is at the mercy of the GUI.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @02:10AM (1 child)
Didn't CP/M had the equivalent command line processor - i.e., cmd.exe's predecessor?
(Score: 3, Interesting) by Dr Spin on Friday May 29 2020, @06:56AM
Didn't CP/M had the equivalent command line processor
Yes, but only because it copied Unix's sh.
Of course, DEC had a better shell at least six years earlier, and no one remembers IBJOB for very good reasons.
Warning: Opening your mouth may invalidate your brain!
(Score: 0) by Anonymous Coward on Friday May 29 2020, @02:19AM (4 children)
Have we not had enough of this Microsoft nostalgia? What is next, the joys of edlin? Please, please, Soylent Eds, save us from this onslaught of operating system perversions from the past!
(Score: 0) by Anonymous Coward on Friday May 29 2020, @03:08AM (2 children)
Good old MS. Where any news is good news.
Tomorrow, let's teach poodles how to fly!
(Score: 2) by MostCynical on Friday May 29 2020, @03:50AM
Everything is air-droppable at least once. [schlockmercenary.com]
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 1, Insightful) by Anonymous Coward on Friday May 29 2020, @08:31AM
Please!!! Just, just make it stop! DOS zombies everywhere. PTSD'ed script boys from the late Eighties! Make it stop! Please, for the love of Unix!!
(Score: 2) by fido_dogstoyevsky on Friday May 29 2020, @05:36AM
Speaking of which, when is the windows version of edlin being released? It was promised decades ago.
It's NOT a conspiracy... it's a plot.
(Score: 4, Interesting) by krishnoid on Friday May 29 2020, @02:21AM (1 child)
Busybox for Win32 [frippery.org] has an Almquist (POSIX-compliant) shell implementation, so you could use it to work up an sh script where necessary. Since it's BusyBox, such a shell script directly calls many the built-in busybox "binaries", without (from what I could see) having to start them up as separate processes.
It's a single binary as well, which makes it very portable.
(Score: 1, Informative) by Anonymous Coward on Friday May 29 2020, @09:04AM
That depends on the command in question and the entered prompt. Something simple, such as an ls or cat, IIRC, will just get executed internally. Pipes or some of the more advanced or unsafe commands, to name a few, will be executed the old fashioned way for a multitude of reasons. But, they are usually lightning fast, especially if statically-linked or don't require a new library, because they will already be in RAM.
(Score: 3, Insightful) by Revek on Friday May 29 2020, @02:45AM (6 children)
learn another mostly useless command line. Why can't they just integrate a real bash prompt.
This page was generated by a Swarm of Roaming Elephants
(Score: 0) by Anonymous Coward on Friday May 29 2020, @03:18AM (1 child)
well?
(Score: 2) by Revek on Friday May 29 2020, @03:33AM
Just about as much as I care about them.
This page was generated by a Swarm of Roaming Elephants
(Score: 0) by Anonymous Coward on Friday May 29 2020, @05:07AM (3 children)
https://cygwin.com/ [cygwin.com]
https://cygwin.com/packages/summary/bash.html [cygwin.com]
I've been using it for decades.
And you're welcome.
(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
(Score: 5, Interesting) by Anonymous Coward on Friday May 29 2020, @03:15AM
google or whatever.
It's coming. Pretty soon now you'll go about your normal search engine of choice, working out some Linux issue, and it's going to be MICROSOFT, MICROSOFT, MICROSOFT, HOOOOOOOOO!
The results will all be fucked, because the EEE will pollute the pool.
Save this post somewhere in the back of your mind, and give it a few years. It's coming.
(Score: 2) by fido_dogstoyevsky on Friday May 29 2020, @05:48AM
Can't comment on powershell, never used it and have no intention of using it. Can't comment on cmd, jumped ship before I had to use it.
Command.com I have used, and found it quite useful after a little tweaking (ie replacing it with 4dos.com).
It's NOT a conspiracy... it's a plot.
(Score: 0) by Anonymous Coward on Friday May 29 2020, @05:53AM
It takes anywhere from 2-5 seconds for it to open. Kinda annoying. A WSL Bash prompt takes less time to open than Powershell, and most of the time, if I'm opening a command prompt, it's usually to just run a single program. Old CMD does all I need in a tenth of the time.
I've also ended up just using bash via WSL on Windows for any actually advanced scripting use at this point. Shift+right-click in a folder, open Linux shell here, do whatever (usually something I threw in ~/bin/). Really fast and easy.
Only thing I'm really missing is like yad for some of the nice GUI wrappers I've made for some commands, because it's not exactly convenient to get X11 stuff going on WSL. It's entirely doable, just not convenient.
Python is nice if you aren't farming stuff out to other programs, and are instead using a bunch of libraries to process whatever you're doing.
If you do end up shelling out a lot, nah. Just more hassle.
(Score: 5, Insightful) by Dr Spin on Friday May 29 2020, @06:59AM (1 child)
from Windows.
Lets face it, it was never suitable for commercial use, or networking, or indeed anything, really.
I blame Ken Olsen for not letting us use VMS on the PC.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by martyb on Friday May 29 2020, @02:12PM
I thought it was clear from "I'm looking to port them to run on Linux"... that is what I am doing.
More precisely, something that provides a GNU userland. I ideally something that would be directly compatible with the Gentoo builds that SoylentNews is moving its servers to.
Wit is intellect, dancing.
(Score: 2) by turgid on Friday May 29 2020, @09:16AM (1 child)
But I thought modern operating systems did everything via the GUI and that CLIs were an admission of defeat?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday May 29 2020, @11:30AM
its the new thing to hide all the important shit from the GUI and make you use powershell.
its fucking annoying, at least in the past you could figure shit out on your own just by looking through the gui, but now you have to google the powershell commands.
(Score: 2) by RamiK on Friday May 29 2020, @10:54AM
When wasn't it in "maintenance mode"?
compiling...
(Score: 3, Funny) by ilsa on Friday May 29 2020, @02:11PM
CMD may not be great, but holy hell did they double-down on the WTF with powershell.
The syntax is shockingly ugly, like C# and Perl had some kind of unholy sex and then through the baby in a blender for good measure.
I'd like to know what combination of drugs it took to come up with that pseudo object-oriented >command @{ y=_$.xxx } syntax.
(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?
(Score: 0) by Anonymous Coward on Sunday May 31 2020, @07:19PM
Looks like the Open Sores Virgins have got a toehold in Microsoft. They couldn't turn Linux into a decent Desktop OS so now they joined Microsoft to make Windows worse.
Backward compatibility has been one of Windows's redeemable characteristics for years or even decades. But they're throwing it away bit by bit.
There's also some Windows stuff that used to have a GUI for but now the GUI option is gone and you're supposed to only use Power S Hell instead. Doesn't that remind you of Desktop Linux? Or is when you have to edit XML files to configure stuff?
(Score: 0) by Anonymous Coward on Thursday June 04 2020, @10:56PM
CMD hasn't been maintained in a while. A couple years ago I just rewrote something that's a spiritual successor and it's actively maintained. Obviously that means it's not included in every copy of Windows, but if you want something that's CMD-like and that is continually developed, see http://www.malsmith.net/yori/ [malsmith.net] .