cmd.exe is dead, long live PowerShell: Microsoft leads aged command-line interpreter out into 'maintenance mode' 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 …
It doesn't always work like that in the real world. Especially on production lines.
Roughly 15 years ago I had a customer in the South West of England who manufactured server cases for a large PC vendor with a factory in Ireland. The IT manager decided to update the PCs on the production line and broke some third-party software my boss had sold them a couple of years before. Note they updated the hardware, not the OS, and installed Windows XP from the same gold master as before. This broke the third-party software which was actually 16 bit, designed for Windows 3.x (barely) and not supported on Win 9x let alone XP. This held up production not only for them but also for their customer and had been ongoing for several days before I was called in as the expert.
I told the IT manager that software was not supported and I couldn't guarantee getting it working on XP but he insisted it would work because it had before. I told him that if it worked before he was lucky. He insisted the gold master was identical to the previous machine so it should work. After an entire day spent reinstalling XP from various media and the third party software on several different PCs, including the original that had worked before, we were unable to get it working.
The only answer was to sell them the modern, supported software for that purpose which he'd been too cheap to buy in the first place. To sweeten the deal I offered 2 days of my services translating their files to the new format for free. The IT Manger refused but was eventually overruled by a director who realised it was that or go bust. I almost missed my flight home due to his refusal to listen but fortunately was able to persuade the nice woman at the desk to re-open check-in for me.
At least when it happens for small business, is due to lack of budget.
It was 2006, they took a 286 machine for a friend to repair, he tried but the hard disk was dead and they didn't even have floppy disks backups. They ended buying a new computer as it was freaking impossible to get a compatible hard disk unless taken from another old machine and that wouldn't last as said hard disk would be really freaking old.
You are, of course, assuming those who made the change are directly accessible to those who run the production line? If not, it's entirely possible it may take a couple of days to report the problem, and may take a couple of days more to work out what had changed, especially if there had been a few changes, and no one had correctly logged the changes (which is entirely possible).
most likely:
a) it was written by a contractor, "the lowest bidder"
b) it's been working for YEARS
c) nobody in I.T. (read: PHB's or a contract with an I.T. management company) has a clue how it works or what might be going wrong
I find myself in the position of being "the contractor" and having to deal with incompetent "I.T. management company/contractor" at times. then you try and document everything as best as possible, and the contract ends, and they may call on you some time in the next 5 years to fix some problem like that. Hopefully you didn't write such fragile code, though...
I still stick with cmd scripts for most tasks, it is just so much easier and quicker to write. I have used PowerShell for more complicated stuff where cmd can't give up the necessary info, but in general the syntax sucks (not saying cmd doesn't suck also) but I prefer the beast I am familiar with. Hope they don't kill it off.
.\example-script.ps -PowerShellSuckage=doesnot -VeryMuch -ButCanResultInCommandLines=VeryLong
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):
..and safe but sometimes quite annoying.
Correct, it's just too Microsofty, at least to me.
I think powershell has the tools, but its syntax is just so intentionally different that every bit of syntax you need to use to take advantage of powershell has basically no usage outside of it. Taking an OOP'ish approach is cool and all, but if everyone that looks at the syntax goes "WTF?", then the game is lost before it has began. It's not a WTF in a simple way either, it's one of those WTF's that cause eye scrunchies.
See also the related unix discussions about replacing Sys V init with things like systemd: some of this stuff may be 40 years or older and, while there have undoubtedly been improvements since then, in the world of system administration "working" trumps nearly everything else. Especially when you have systems that have up times for 10 years or more.
YEARS ago I wrote a command line interpreter for windows 3.x that extended COMMAND.COM commands with a bunch of power-shell-like things (task lists, poking character strings into windows, starting windows applications in the background or synchronously, and so on). When Win '95 came out I abasndoned it for a couple of reasons, not the least of which was being able to type in a windows program name in '95 and still have it run in windows (as you might recall, this did NOT work in 3.x).
I suppose I could "resurrect" some of that code if an open source maintained version of CMD is still needed.
Worthy of note: I actually implemented the 'format' command to format diskettes within windows, and it did so efficiently (you could format while using the computer for other things). I also found a bug in either '9x or NT 4 where it wasn't actually low-level formatting the diskette, just "checking the format" if the track was already formatted [the OS did this internally, beyond control of the API calls or whatever it needed]. I reported it but I don't think it was ever fixed.
Alternative: use the CMD.EXE from ReactOS
We'll leave it to our readers to debate the pros and cons of writing a script that depends on the format of a copyright string in order to keep a production line ticking over.
The world runs on those kind of things quite often because text is all you get from the relevant system and if you've looked at a couple of bash scripts you'll see the same: query something for its version and parse the response. More annoying perhaps, is the lack of flags on command line tools in windows combine this with the prediliction for localisation on Windows and reliably getting system informatin becomes a chore. Though I've just found that systeminfo /FO CSV returns something nearly usable.
We'll leave it to our readers to debate the pros and cons of writing a script that depends on the format of a copyright string in order to keep a production line ticking over.
But that would require a spec for the string, stating which parts are guaranteed to unchangable and which might vary in different editions.
Supply me that spec and I'll ensure I parse it safely.
And that spec is where ?
The problem lies not with the programmer but with the vendor.
No, I think there are two faults: one with the programmer and one with the vendor.
The vendor's comes first: they need to make a better method of figuring out what version of things is being run. They have lots of methods, but as pointed out they don't have a specific format.
But there's also the programmer. It's pretty clear that trying to extract version information or really anything from a copyright string is bound for failure. It's not meant to include all that information. The internal string that gets rendered could be any of these:
"Microsoft Windows Version 10.0.15926536, copyright 2001-2020 Microsoft Corp"
"Microsoft Windows Version 10.0.15926536, copyright 2001-{$current_year} Microsoft Corp"
"Microsoft Windows Version 10.0.{$patch_version}, copyright 2001-2020 Microsoft Corp"
"Microsoft Windows Version {$major_version}.{$minor_version}.{$patch_version}, copyright 2001-2020 Microsoft Corp"
"Microsoft Windows Version {$version_number_string}, copyright 2001-2020 Microsoft Corp"
Or even "{$product_name} Version {$product_version_string}, copyright {$copyright_start_year}-{$current_year} {$product_vendor}"
And that's just a few of many possibilities. Relying on that isn't a good idea. It's bound to break, and I'm surprised MS did anything at all on hearing it. I'm actually surprised they did hear about it--if I had written a script and it broke, I wouldn't anticipate any assistance from them and I would have found some other method to get around it.
> More annoying perhaps, is the lack of flags on command line tools in windows combine this with the prediliction for localisation on Windows and reliably getting system informatin becomes a chore. Though I've just found that systeminfo /FO CSV returns something nearly usable.
Surely Microsoft provides an API into its telemetry database so that you can easily query what your own machines are running?
The point about the CLI is not the cmd/bash you use, its EVERYTHING supports starting sub processes with command name and args and handling the streams and exit code.
_everything_ works like that.
Not just shells, but all languages C, c++, python, perl, awk, everything can start a program using this totally ubiquitous interface.
All build tools make, maven, grunt, npm, jenkins travis, git hooks support this interface.
Powershell API is nonsense, it misses the point entirely.
PowerShell ignores everything that exists and tries to tell you they know better,
"PowerShell is better than CMD.EXE" but it is wrong by definition, its comparing a shell that is able to run every application ever written and something that thought what was cool about the shell was that you typed instead of clicked and could write scripts. That is cool (bit clunky) but that is not the point.
What is cool about the CLI is that EVERYTHING integrates. Well or Badly we can argue about that over a pint, but it is always possible (outside of Microsofts world).
The CLI is the worlds most simple application integration interface and Microsoft still dont understand it.
Looks like they never will.
Yeah, there’s a reason that UNIX / Linux scraps the command shell standard and adopts a new incompatible one instead every five years maximum. :-) (what is it again?)
sh, ksh, bash, yash, cash, credit, cledit... I imagine no one remembers them all, partly because I made up at least half of those.
Bash has been available via the likes of cygwin or mingw builds for years; but the Linux subsytem may simplify things (...wait, this is still Microsoft we're talking about?).
Does anyone remember the original POSIX subsystem that came with Windows NT?
That was a _minimal_ POSIX subsystem which satisfied US Gov requirements intended to u/g their UNIX systems. Unfortunately they didn't specify a level of POSIX requirement, so MS added the minimal qualifying support and undercut the Big Iron UNIX vendors. Queue lots of unhappy end users presented with systems which wouldn't run their existing code...
"Does anyone remember the original POSIX subsystem that came with Windows NT?"
I installed this on XP and 7, but with limited usbility. i tried working with it (it had X11R5 libs!!!) and tried to get configure scripts to work properly [oh the horrors...] and gave up out of frustration.
It did change names a few times - Interix - then SFU - then SUA. I think that's right. The original version would work on 'Home' versions of XP though, as I recall.
Cygwin does NOT have those "Home vs Pro" restrictions. Sensibly.
Powershell would be more popular if it had been backwards compatible with the Command Prompt.
For example "dir" aliases onto a cmdlet called "Get-ChildItem" which has an entirely different syntax to either "dir". Why not alias it to a "Cmd-Dir" cmdlet which does what its name suggests?
If Microsoft had done this for all the common DOS / Command Prompt commands then there would have been a migration path. Instead they provided two shells, one supported by any version of Windows and another which was an incompatible, moving target and surprise surprise many people stuck with the former.
That doesn't mean I love Command Prompt but it works and if I needed anything more I'd be inclined to write it in something better than Powershell anyway unless I had no other choice.
"If Microsoft had done this for all the common DOS / Command Prompt commands then there would have been a migration path."
Exactly why I haven't taken the time to learn PS, but I remember many of the batch tricks from my high school days (mid '90s -- DOS 5/6 and Win95). Learned a lot back then from PC World's PowerBase disks (from the Star-Dot-Star column) vols. III and VI. (You know, back when 5-1/4" was still a thing.)
If some of you Reg readers were the ones whose tips were on those disks, thank you.
> The main question though is, why are Powershell commands so verbose?
Because PSH is optimised for maintainable scripts, rather than for doing everything as one offs from the command line or just playing code golf.
Code golf can be fun, but if you need to fix things at 2am written by a colleague who isn't available with a whole host of managers and their managers demanding a fix, being extra clear makes things less hard.
The idea is to make it as close to unambiguous as possible what a command is going to do. There's also an element of consistency and thus predictability. So for the most part a command/cmdlet/function/whatever should be in the form Verb-Noun, with the verb picked from a pre-approved list, and each parameter should be explicitly qualified rather than relying on positional parameters.
In this way it means it's extremely easy to sanity-check a sysadmin script before running it. However it does mean that no matter how good PS is at sysadmin stuff, it straight-up sucks as a programming language. And all of the consistency and predictability that sticking to certain coding standards will earn you is completely trashed by the actual language itself acting like a spoiled brat with undiagnosed ADHD whose main purpose in life seems to be to violate the Principle of Least Astonishment from as many different angles and in as many different ways as possible. When used as a programming language, and especially if you expect it to behave like a "proper" one, it's probably one of the most dangerous things I've seen in my career (which is admittedly not a long one, nor something I would call a career).
The verbosity, though, means you can actually usually take a correct guess at the command you're after, and its parameters, without having to Google what you're attempting to achieve. This is one of the few things I think is interesting-in-a-good-way about PS.
"The verbosity, though, means you can actually usually take a correct guess at the command you're after, and its parameters, without having to Google what you're attempting to achieve."
I'm glad that works for you. It doesn't work for me. I usually have no clue what a command is called, and I am often very baffled about how I'm supposed to extract parts of the results. I have to wonder if part of the reason you know these things is not that it's so clear and standard, but that you've used it enough that most things you want to do frequently you've already seen--while you may not have memorized them, you can take guesses based on having seen them before.
The problem with PowerShell is that it's intended both as a CLI system and a programming language. Not a scripting language, but a programming one. Meaning lots of things like exceptions and type confusion which can be harmful. Consider how a user interacting with it as a CLI sees certain elements. An easy example is error messages. Let's compare some error messages printed by unix tools and PowerShell commands:
Listing a nonexistent directory:
me@machine:~$ ls /doesnotexist
ls: /doesnotexist: No such file or directory
PS C:\>ls c:\doesnotexist
ls : cannot find path 'C:\doesnotexist' because it does not exist.
At line:1 char:1
+ ls c:\doesnotexist
+
+ CategoryInfo : ObjectNotFound: (C:\doesnotexist:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
Copy a file onto itself:
me@machine:~$ cp file1 file1
cp: file1 and file1 are identical (not copied).
PS C:\>copy file1 file1
Copy : Cannot overwrite the item C:\file1 with itself.
At line:1 char:1
+ copy file1 file1
+
+ CategoryInfo: WriteError: (C:\file1:String) [Copy-Item], IOException
+ FullyQualifiedErrorId : CopyError,Microsoft.PowerShell.Commands.CopyItemCommand
Yes, the information is there. The error messages are possibly a little better, in fact. But the rest of the data is useless and it gums up the output stream. It's all there because people are expected to run these commands in scripts and catch these things. Well, let's say I'm writing a script to copy things and I want to catch the copy-onto-itself bug for some reason. What do I catch? Look at that error printout from earlier. Is it WriteError? IOException? CopyError? Which of these can I even catch? What else might cause that but not be this particular error? Is there a CopyFileOntoItselfException?
None of that is obvious. An easy method to find out is to go online. What if I don't want to? Well, on a unixy OS, I can do "man cp" for a full log or just run cp with no arguments to get a summary. What about PowerShell? Maybe just "copy" will do the trick:
PS C:\>copy
cmdlet Copy-Item at command pipeline position 1
Supply values for the following parameters:
Nope, that's not it. Might they have made a man command for me? Yes, they have. While we're on the subject, I'm noting here that the only way I can find commands is by entering their unix versions and seeing if someone at PowerShell HQ has linked them to me. While get-help is not that hard to guess, I could see several other options such as get-documentation, describe-command, show-manual, and various other things.
Let's try "man copy". It pulls up a typical man page, except the basic one doesn't really say anything. It talks quite a bit about the command being able to copy and rename a file in one command because well, duh, but it spends only a couple terse lines talking about parameters and doesn't mention errors or exceptions. There are two other views, detailed and full, and maybe one of those contains that information. Detailed doesn't. Full doesn't. Finding out that neither does takes reading long man pages with very long examples sections.
So if I want to use it as a method of launching things, I end up having to see plenty of pointless details that only matter if I'm writing programs. If I'm writing programs, I have to hunt the internet for information about what a command can do. They should start with a good CLI and build the scripting onto that, but they didn't. It shows.
Yes that too. Powershell could have supported personas where it can mimic the command prompt or Unix. Then it starts to be compelling since it is instantly familiar with people coming from those environments while exposing powerful new features. But it didn't.
I'm sure whoever wrote it had no consideration for a migration path and Microsoft thought they could coast on awesomeness into this brave new world. Except it didn't happen. And now they're still stuck between a rock and a hard place.
Initially you could install MSDOS from a single floppy disk, then they "upgraded" to Windows and you needed half a dozen floppy disks, then along came NT needed a couple of dozen floppies, then we progressed to Vista and Windows 7 needing a CDROM to install an operating system, then you needed a DVD and finally Windows 10 "upgraded" to installing a few gigabyte from the internet.
Will the next release of Windows need a terabyte or two to "upgrade"? What kind of idiots think that this is improving life? Every app they "update" gets bigger and runs slower.
Anything that is compatible with CMD can only do things that an extended CMD could do. Once you've decided that you don't like some of the things CMD does, you might as well start from scratch. PS is much better than CMD once you've bitten the bullet and learned the syntax and, frankly, there are far worse languages out there.
but.. but... DevOps
DevOps is cool
What do you mean you work in small business and only need to do thing X once every 3 years for about two users at a time?
NO! You must learn all of Powershell. Oh, and by the way, we've replaced the command you used a year ago. WHY AREN'T YOU PAYING ATTENTION?
Okay, we used to give you a GUI, where you could just click on a tick box and it would set it for your whole organisation, but now, you can write a 20+ line script to do that.
DevOps! DevOps! DevOps! (You're still using Insta - TikTok!) DevOps! DevOps! (You didn't go to the cool party?) DevOps! Trying to maintain the mystique and inaccessibility of IT? DevOps!
Nnnnnnaaaaarrrrrrghghghghg!
An update pushed out by MS (bless their cotton socks) removed a crucial part of the MCSC cluster service that was controlled by Powershell.
That meant we could not manually fail over the cluster.
Wonderful
Magical
Tremendous.
Took them a week to supply a fix. Three of us sat on our thumbs in an expensive foreign hotel waiting for it. Once we got the fix, we could carry on with the system acceptance tests.
I wish Powershell would die sooner thather than later.
and 4DOS as well.
Powershell seems so slow, I have seen it take 30+ seconds to launch or to execute a command (especially after initial login to a server). I'm sure Powershell is a real great tool, though as someone who grew up mostly on linux(since about 1996 anyway), I am more used to(and so prefer) shells/commands using strings rather than objects. With the registry and other things on windows I do realize that strings are harder to use with windows vs the text file config on linux.
I have used bash from cygwin using rxvt on windows for 15+ years now I think(still use it almost daily), unfortunately a few years ago the cygwin team retired the native rxvt that I rely on(had to go to the developers to figure out where it went as there was no mention of losing it at the time), so using old cygwin while I can (which probably doesn't work on the latest windows). The alternative from them was running the full X11 rxvt instead of the native one which isn't what I wanted.
4NT/4DOS still exists, and is still updated and developed by the orignal author. It's just that the name changed ... it's called "Take Command" now.
There's even a free-but-without-support version called TCC/LE.
On Windows I always have a TCC window open, and usually an MSYS2 BASH window as well (gave up cygwin years ago), but I never ever use Powershell.
Why bother with a clone when the real thing is already there?
https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7
That said, even though I use PowerShell extensively on Windows, I've rarely used it on my Linux boxen.
I was leaving one Dutch company and my replacement chatted on the phone to a customer about Dot Pat files. My Indian English junior said, "Did he just say Dot Pat?", and I replied, "Aye, noo ye'll miss me".
I'd taught the English Indians a lowland Scots dialect so we could chat alone when the Dutch broke into Dutch - supposedly an English speaking company. I learned a wee bit Punjabi. And also how to freak the Dutch out - just wait until they've finished their chatter then say 'waarom niet'?
Yeah, that's going to be the issue for me too. I have lots of little CMD files in various Task Sequences in SCCM, because things like registry adds and file moves are much quicker to write and much easier for people to understand once I'm gone in CMD than they are in PowerShell.
A prime example is installing .NET 3.5, which is still an often required pre-requisite sadly. IME (this might just be me) the PowerShell methods for installing this are wildly inconsistent and less than reliable, whereas doing it from a CMD file via DISM is pretty much bulletproof.
Not at all is the better answer. While the commands have aliases, the parameters very much do not.
Consider this command that I've used with some frequency. If I know a file is somewhere in a crowded directory and part of the filename, but I can't find it, I can do this to give me the full path:
dir /s /b | findstr [name]
Not a clear command. Neither /s nor /b are clear; you just have to memorize them. What happens in PowerShell? Neither parameter is recognized, and they're treated as paths. There are certainly replacement parameters. However, I would need to look them up. Instead, I'll just move over to git bash and use the real ls and grep to do it properly--the dir way is faster only because I have memorized it.
PowerShell demands a different way of thinking, and since Windows is based on API calls and not on text files something "shell-y" like cmd or even bash would never work. Unless you want to go back to VBscript syntax as a shell. Do you? I don't.
I'm finding it very *discoverable*.
PS> Get-Something --> receive objects, objects have properties and properties have values
Want to see only some properties?
PS> Get-Something | Select Property1, property 2 ! Format-Table
Want to filter by value?
PS> Get-Something | Where Property -eq(*) value
(*) almost the same comparators as bash test
Found what you want to change?
PS> Set-Something -Name thingamajig -Property pants -Value leather -Enabled
It's not much different than using sed and awk to filter data until you get information. You just have to know how to look for what you need, instead of memorizing netsh, net, netdom, and all the other stuff. Because cmd, without those other utils, is hopeless. And those utils still work in PowerShell, for now.
I'm wanted to find out what version of powershell I have. So I opened it up and tried ver (the cmd.exe equivalent), and then version and help, all with no luck. I had to hit google to find out it's Get-Host. As newbie, it wasn't the thing that popped into my head.
Interesting. As a none-PS user myself if I'd been flicking through a manual looking for potential commands, I'd have skipped Get-Host as most likely being a command to get a) the hostname of the system or b) maybe more verbose and give current network config info too.
(Anyone else remember the good old days of actual dead tree manual you could rapidly thumb through looking for headings to jog memory and find the command or instruction you needed rapidly? It's rarely so quick to search a PDF or help file.
... interesting enough to tolerate its infantile syntax is the remoting capability. But then MS had to go out and neuter that when used against their own services because allowing it would crumple their servers*.
Want to set a simple property on all your O365 e-mail accounts? Sorry. Only on the 1st 100 or so. For the rest, you need to transport the entire collection to your side, change the property, then send the whole lot back. What should have taken a few seconds now takes an hour.
* anno 2018.
I used to work in a company where there a production machine operated by a PC could not run on anything faster than a 66Mhz clock.
So I had to keep a pile of 486 PCs just in case that one broke.
The machine was controlling a production manufacturing equipment worth over £1m and was built in the 90s
I had a quote to replace the control system, price was over £100k. lets say it never happened as the boss baulked at the cost.
So still had to keep that 486 PC working, somehow.
In the ideal world we would all like to be using the latest stuff but that just does happen.
Given that windows search has been broken for SO long... I always revert to dir c:\<whatever> /s /b to find files with wildcards on my work PC. It runs almost instantly. Is there a powershell equivelant of that? I found the syntax so bizarre and verbose that I gave up with it long ago...
It *is* still handy on locked down machines though, as admins often forget it is there and leave it open.. so I heard, anyway ;-)
To druck: yes, cmder is a great alternative to cmd, especially coupled with far commander.
To Furbian: That's why I don't like PS. It goes against the grain of *nix philosophy re small, easy to remember helper programs. Sure, PS has piping, but it's like writing a German opera. Ugh. (No offense to anyone who speaks German, your grammar is just a little ... verbose.)
What made Cmder shine was its *nix philosophy and baking the old unxutils port into it.
One might say Cmder's days are numbered, as the new WSL seems worthy of use. However, Cmder already supports spawning shells in multiple terminal types (bash, cmd, cmder, PS), and does have a nice tabbed interface, so may have more life left than we know. Will just have to see...
I still miss the Digital Command Language from VMS. The inline help system was good. Commands had many features, so if you knew how to do what you almost wanted, you might find that same command had another option that made you happy. It had a very rich logical and lexical system. Command lines tended to be verbose, but that also meant they were easy to read. And the error handling! You could see not just that your command failed, but where and why.
It's quite different from UNIX. I could make the same unflattering comparisons that we're making with PowerShell now, and appreciate both sides.
Anyway, I'm curious: is PowerShell much like DCL? On the surface, it has some common elements, but I haven't used it enough to really understand.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
