Command Prompt has been around for as long as we can remember, but starting with Windows 10 build 14971, Microsoft is trying to make PowerShell the main command shell in the operating system.
As a result, PowerShell officially replaces the Command Prompt in the Win + X menu, so when you right-click the Start menu, you’ll only be allowed to launch the more powerful app. Additionally, in File Explorer’s File menu and in the context menu that appears when pressing Shift + right-click in any folder, the old Command Prompt will no longer be available.
Typing cmd in the run dialog will launch PowerShell as well, so Microsoft has made a significant step towards phasing out the traditional Command Prompt.
It’s funny – cmd has always been seen as a sort-of Baby’s First Command Line, and compared to the shell that comes standard with any UNIX-based operating system, that was certainly true. However, now that Windows has a replacement that is much more capable than cmd, people will cry foul and hell over the possible deprecation of cmd.
Us nerds are fickle.
Other than the slowness of PowerShell, are there any applications we’re used to launching from cmd that won’t work in PowerShell?
A quick ‘sc \\COMPUTER stop SomeService’ in powershell always gets me. SC is shortcut or alias to Set-Content, so I have to specify ‘sc.exe’ whenever I’m using powershell instead of CMD.
I really don’t use much of powershell for launching scripts or apps, unless they require powershell.
CMD should just have been used as a starting point and expanded, which would have been fairly logical, but that’s the kind of disjointed stuff you get in large companies.
Here, here!
CMD is reliable. I can write a batch script and it will largely run as-is all the way back to a genuine MS-DOS machine. Now matter how borked a PC is, CMD will still work. It’ll work in safe mode, it’ll typically be the only thing working when .NET has corrupted itself for the umpteenth time.
CMD, despite all its shortcomings, is the go-to tool when you want to write something that will absolutely not dick around with you and you can rely on running the same on every PC you can imagine.
This news brings me great sadness because here I am polishing an awesome 1000-line batch script that’s quite a thing of beauty despite the language’s idiosyncrasies.
I like CMD for running scripts, but I totally hate batch scripts for more than a couple of sequential commands. I replaced stupid vbscript with jscript (which is much better thanks to exceptions) and then started using powershell for more advanced stuff. It really shines for WMI querying.
I think that’s the point. It’s really awesome at what it was designed to do, namely, be a scripting language to handle complex, windows-specific queries. It was, however, clearly never designed with interaction as a top priority and it shows when you use it as an interactive shell.
I don’t think anyone here is saying that Power Shell is terrible. It’s not. It is, however, no good at what Microsoft is trying to push it to do at this point.
Groan.
It’s “Hear! Hear!”
There, there.
Used cmd to create a 1100+ lines, 46+ kiB batch file, yet it has been hell to write and debug, io and string performances are horrible, delayed expansion made things ridiculously complex and the 8191 chars limit for a string definitively ruined everything. Will convert it to PowerShell and Linux shell as well.
Hear hear!
While I liked PowerShell back in my windows days, CMD has always been my favourite for two reasons:
1) I know it well, and
2) It is snappy.
It comes handy when you have to help friends and local residents with their Windows systems. (The price of being pretty much the sole nerd on an island with almost 200 residents.)
I was under the impression that if your command script was .bat is operated like a batch fiel always has and if it was .cmd if used the newer methods.
.bat and .cmd are executed the same way. The extension you use is mostly an indication of how old/experienced you are
PowerShell use the .ps1 extension
Okay – that sounds like you are doing something wrong. When has this ever happened in real world? I’m sitting here, developing against .Net with a very large customer base using apps for mission critical (read: life saving) applications. If this was true, I think we’d have noticed by now. Please, back up your personal anecdotes with actual facts, or stop spreading FUD.
Please, stop being an asshole. Just because something has happened to someone else and not to you does not mean they are lying, and there may not be references for them to use if it’s something obscure. I’ve personally seen .NET go belly-up before when an update from Microsoft improperly applies and does not completely revert, leaving the system with mismatched core files. Of course, you’re going to accuse me of lying and saying it has never happened, right, just because you have never seen it?
No, because that is not what he was implying. He was implying that it happens regularly (umpteenth time – more times than he can count), which is anecdotal bullshit. Yes, I believe that any piece of software can fail when it updates, but .Net rarely updates, even less going forward with Core, and when it does it is trivial to fix in almost every occurrence. But when it fails to update it is usually down to some oddball extension in the OS on that machine, or a global issue with that specific update. It does not “just corrupt itself” for no good reason and it was that exact FUD I was asking for proof of. Kroc being a (former?) contributor here, should know better.
None of this is being an “asshole”, because asking for proof to unfounded claims is a completely justifiable position.
Perhaps the good thing about very simple shells is they’re intended to be extended via extra command line software. The only limits are to core parser logic (which in CMD’s case, is quite old and limited.)
So like many other readers here, I have accumulated my own tools to work around CMD’s age. The one I’m most proud of/use the most is sdir, which attempts to make dir a little less 1981. If anyone reading this is interested, it’s at http://www.malsmith.net/sdir/ . There’s also other tools at that site for copying HTML to the clipboard and manipulating ANSI/VT100 escape sequences, manipulating Windows shortcuts, finding where things are in a path or environment variable, etc.
I’m also curious what other readers here have done to make their CMD experience more pleasant.
As long as I can still type “cmd” in the run dialog (deep deep muscle memory there) and all the traditional commands execute, I don’t really care if it’s PowerShell or not.
Having said that, I think there are things I’d prefer much more than switching which command prompt I use. How about tabbed terminals like I get in MacOS?
hah. That’s how I usually launch cmd.exe, even though I have the icon on the taskbar (Which is more convenient for launching elevated prompts)
I like the idea of PowerShell but my goodness it is slow. They really need to improve performance before making it the default.
Apparently they don’t, seeing as how they’ve done just that. Seriously though, I do agree. Launch times alone are excruciating so it’s a good thing I tend to leave my command windows open anyway. What I really want is a truely native, high-performance bash shell in Windows that integrates with Windows’ built-in environment as well, but I know of no such thing. It’s one of the many reasons I still prefer MacOS, despite all of its faults.
Anyone know of such a bash shell? The Linux emulation layer on Windows doesn’t cut it (try running nmap in that and see what happens) and cygwin is yet more emulation and even slower than PowerShell.
darknexus,
Have you tried the msys shell?
You may or may not like it, but you should give it a shot. I use it with a mingw compiler variant for porting linux software to windows. I prefer it to cygwin, I even used it to produce windows drivers back in the day prior to being locked out of the windows kernel by microsoft…but I’m getting off topic.
/+1.
Though, I’d get msys2 which is fully supported, documented and uses a modern package manager.
(We are mostly a Linux company, and use extensively when we need to work on Windows VMs)
– Gilboa
from my life.
MS is doing is best to alienate its users.
A triple barrelled footgun moment if there ever was one.
It apears that they did this with no warning to users.
Why? Do they want to piss people off even more than they already have. I guess they don’t care any longer.
Has that ever changed? They had been alienating their users for decades, and people (and companies even more) still need Windows.
I’ve tried to use powershell at work as a primary shell. It’s not terrible, but the commands are way too long. I can’t remember them very well. Whoever designed that shell had never intended to use it for anything other than writing scripts in my mind.
Just use a unix shell already!
Fortunately tab completion and Get-Command come to the rescue. Between the two of them I pretty easily track down the command that I’m looking for, and if I keep using that particular command it gets retained.
Get-Command is all well and good but….
A couple of years ago, MS issued a Server 2008 R2 patch that removed the MSCS library. How the **** do they think we could manage the MSCS stuff on a system with no GUI.
Took them a week to issue another patch to restore it.
Is it any wonder that I think PowerShell sucks big time when they can remove key fuctionality with no warning…
I don’t object to long winded commands. I did use them with DCL on VMS for years but… if you got to a point in a command structure and you needed help you could just add ‘help’ and you’d get the options available at that point and often an example of its use. The MS Implementation is a long way short of this and DCL was designed almost 40 years ago. They could have done it right but they didn’t. NIH rules OK!
Most commands have much shorter aliases available. The longer command forms are great for scripts, though, as it improves readability. It also helps with understanding for newer users…
They better not interfere with cmd-based Far Manager! I can’t live without it!
Since now MS S2 Linux, why not replace cmd and powershell with Bash?
That would be a very sane move. Unfortunately it’s microsoft we’re talking about. They’ve always just copied (badly, see Aero vs. Compiz both in terms of performance and effects available) what was in Linux long time ago. That’s their thing and I don’t think they’ll be doing any sane moves in future.
The only thing Microsoft ever did right was C# and only because they’ve stole chief architect of Delphi from Borland.
1) Because PowerShell is completely different from Bash. It is Object Oriented instead of Text Oriented. The easiest way to describe that as a benefit is $credential = Get-Credential, which results in $credential having both the username and password in 1 object that can be passed around.
2) Because all Microsofts managements tools have been written in PowerShell the last 10 years! So even though PowerShell is only 1 of many commandline tools it also gets extended by cmdlets/snapp-ins to manage Exchange, SharePoint, and basically every other Enterprise tool they have.
http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_10_02.html
avgalen common the Object Oriented example people give is wrong. Bash does have arrays. So $credential holding username and password is possible in bash. Would it have typing information for what is in there not it would not. Object Oriented is type on stuff so you cannot randomly shove X type data into A function and have it explode because it was only able to process B type data.
cmdlets/snapp-ins is in fact Powershell biggest fault. Why is cmdlets/snapp-ins can provide the same function name that does something completely different to each other. In scripting language this is fine. In a language expected to be operated by the command line where a person may have more than 1 window open with different mixes of cmdlets/snapp-ins loaded this is absolutely not fine as it a path to human error.
Powershell was more designed as a scripting language than a usable shell. Few different things forbid like making cmdlets/snapp-ins be prefixed and unique as a rule so fixing the current overlapped commands to hell issue.
Mind you powershell is not as hair pulling as using python shell mode.
http://www.python-course.eu/python3_interactive.php
It also does not help that cmd that some of powershell ideas come from is not that advanced. People forget 4dos shell. So extending cmd to something more decent would be importing some MIT code.
https://en.wikipedia.org/wiki/Comparison_of_command_shells
Pay to read here avgalen. Notice Interactive featuresfish exposes straight on the command line you have to use powershells ISE to get access to those features.
Yes powershell command line is for features included around bash level but it has brought in particular bugs. Is powershell near the easiest shell to use no way.
Really we need to be asking powershell to be competitive against fish.
Bash is the bare min in Interactive features any modern shell should provide to be usable. cmd.exe/command.com in windows should have be updated with 4dos shell features ages ago.
Most of the things wrong with powershell are fixable question is will Microsoft put in the effort or will it be like cmd/command where it remains defective for it complete life until it deprecated.
Thanks for those links, they were very informative!
I didn’t know bash could use array-variables. It is indeed a way to pass multiple, related variables as one, but not a very good way. How would you know if credential[0] or credential[1] is the username? You wouldn’t unless you always code this the same way and so does everyone else.
I never heard of Fish, but from you shell comparison link it seems like PowerShell IS at least equal. Actually from that comparison PowerShell seems to be among the most advanced and developing the quickest.
I do agree with you that I don’t actually see PowerShell as a replacement for cmd.exe but more as a replacement for VBScript and JScript. Nobody I know uses PowerShell for regular terminal/commandline tasks so we never enabled the “put PowerShell as default” option so far. We did put a PowerShell shortcut on the taskbar for IT-Pro but not for others.
I don’t want to work on a computer without WinKeyX+c for a regular cmd.exe and WinKeyX+a for an elevated cmd.exe!
fish full name is Friendly Interactive Shell. Fish is not object designed language and the question becomes does object language even suit an interactive shell.
The reality for Linux and BSD users is that you need a object script you are going python or ruby or if you are old school perl.
There is quite a difference between a scripting language and a interactive shell. Interactive shell you only really have 1 line of code to-do stuff. Something like fish could be a drop in for cmd or bash because that is what it designed to-do well is individual lines. ISE on powershell is designed for full scripts.
Now could powershell be extended to provide good interactive shell most likely yes. Would it be a good idea maybe not.
Its like debian in sysvinit start up-script used dash not bash because dash is lower in features so lighter. Its also why bash shell scripts are used instead of python or ruby or perl sometimes you don’t need the complexity.
**I don’t want to work on a computer without WinKeyX+c for a regular cmd.exe and WinKeyX+a for an elevated cmd.exe!**
If you be truthful with self you most likely would not care that much if powershell was like fish and it would hand hold you though the change of using it as a interactive shell. Short term minor annoyance. Issue is powershell is not that great when you restrict yourself to using it only interactively.
The biggest thing that annoys me is I can see many minor changes that would move powershell from being painful to use interactively to being nice. I don’t hold out hope for how long 4dos features were in existence and Microsoft never took them into standard cmd and command.com. Maybe this time Microsoft will surprise me.
You really seem to be in love with Fish, probably because it suits your need of a shell the best. I do agree with you that cmd (and probably fish) are much more efficient shells for simple tasks, but I wouldn’t go as far as
If that were true you wouldn’t have variables for example.
PowerShell is by far my most used scripting language at the moment, especially when using Microsofts Management Tools.
PowerShell is nice for certain things, but it is *not* a user-friendly shell. If you’re scripting, it’s fine to write a script against; but it’s still no Bash shell and never will be.
CMD is a pretty nice little shell. Sure, it’s not bash but at least I can use GNU Win32 Tools with it to make it somewhat of a modern shell for usage, and while it doesn’t have the programmability of PowerShell or Bash, it’s still a very user-friendly shell.
Oh, and since PowerShell includes in its user-interface the ability to manipulate the registry just like a directory…yeah, I wouldn’t want any user touching it unless they absolutely knew what they were doing – that’s just dangerous.
I’ve tried picking up bash recently, and although I have no idea how it fairs against Powershell, I honestly don’t find it to be that user friendly at all. Esp. with some commands ending in ‘2>&1’. Yeah, I know what that does, but it sure as hell ain’t obvious when you look at it.
And some of its commands needing a ‘-h’ as a human readable option; what kind of masochist would design something with the human readable option turned off by default? I probably shouldn’t ask that, because I know somebody is going to reply with something like, Well, you see, in 1971, when computers ran on hamster power and had 2 bytes of RAM …’
Edited 2016-11-18 21:12 UTC
I can kinda see the reasoning – back in the day, most files were maybe 10s of kilobytes in size, so using M and K prefixes was unnecessary. People wrote scripts to pull numbers from various outputs. Now, when file started getting large enough, and programs started getting human-readable file size options enabled, having them default to that would break scripts.
In powershell, of course, it doesn’t matter. File sizes (and similar numbers) are just properties of an object, so when you pass the property, it gets passed as an integer, so you never have to worry about it being converted to a human-readable number, because it always only exists as a number, period.
Well, that’s more a tools not a shell issue.
Bash provides some built-ins, but primarily makes use of a lot of scripts and programs to do the real work. What Bash does by itself though is pretty friendly to the user.
With respect to PowerShell, there’s lots of shortcut names for scripts; and they’ve added a lot of defaults that conflict with the Unit tools. So you can’t integrate tools like the GNUWin32 ports of the Linux tools – and now the Bash on Windows won’t integrate nicely with it either because it’s extremely different.
PowerShell just works extremely differently from other shells. It does what it was designed for well, but it wasn’t designed for end-user usage.
Really? Every reference of this I’ve tried to find are examples of people misunderstanding variable scope w/r to the ISE, or variable precedence. I would honestly like to know more.
That doesn’t make bash user-friendly by default though. It just makes it as user-unfriendly as the others. Surely, we can do better in 2016?
I don’t want bash to be user friendly, I want it to be functional and easy to use – not for the masses, most of them never even hear about it, but for us, for the freaking people who actually use it. And no, don’t need it to become something “user friendly” so Mr. Average Dick can think he becmae a shell guru overnight and we end up with a former useful tool turned into a pink unicorn sh*tting daisies in a very user friendly manner and being totally useless.
I’ve done some scripting in python, which is both user-friendly AND powerful at the same time. There’s no reason a shell can’t be as well. I guess holier-than-thou pricks like you don’t want it to be, but whatever. It still doesn’t negate my original point that bash definitely isn’t.
I’ve done my fair share (more than?) of Python, Bash, Batch, and other kinds of programming.
Shell Scripting (Bash, Batch) is something a little different than all the rest (Python, JavaScript, etc); you don’t get the ability to write several lines and link them together to do stuff, and keeping shells working generally the same helps people be able to switch between them – which they need to do a lot more readily than they do programming languages.
So….having the common use of 2&>1 to redirect helps people in many ways. Variables in shell scripting don’t quite work like they do in full language environments (e.g Python interpreter).
All that to say – you have to stop expecting features of full dev environments (e.g Python Interpreter, JVM, etc) to that of lower forms (e.g shell scripting). They are targeting different use cases, different needs, etc.
Oh, you are one of those. Remember that computers are tools and user friendliness isn’t the same as having unicorns…
Honestly, unless you’re a programmer or admin, you don’t know what “standard in” and “standard out” are and wouldn’t need to know how to do that stuff.
Now, keep in mind too that these are also very old interfaces – 1 and 2 refer to the file descriptors, again details only a programmer would really know.
That said, I do agree that it’d be nice if there was an easier way to do the redirects, but there’s only a limited amount of syntax you can do to accomplish what they do, and they’re pretty good for what they do.
Writing scripts for bash is an extremely popular thing to do and there’s no shortage of cases where human-readable output is either non-preferable or unusable. About the only time I use human-readable is for quick overviews of something. The more of a bash’ist you become, the more you’ll probably agree that -h should not be the default.
I have very rarely found it not to be useful for human readable output as an interface between scripts/programs. When it’s not, you’re usually doing something larger and can then have tools to make the conversions while debugging. But most of the time, plain text is more than sufficient.
lost me at forwarding cmd.exe to powershell. the last thing linux and unix are about is removing your ability to use an old ubiquitous program
Heh, I’m itching to see what happens in the reverse direction, where PowerShell has to hand complex scripts back to cmd.exe because it has no chance of executing them itself. That core cmd code can’t possibly go away.
Windows is not a UNIX-like OS, so what’s with the comparison with Linux and UNIX?
The comparison is because MS has seen fit to allow a Linux shell to be used with their precious operating system.
All part of their new love affair with Linux. How long this will last I really have no idea.
It will last as long as there’s a business motive for it.
This is clearly something that shouldn’t happen. cmd means cmd.exe and not powershell.exe. Clearly some manager gave the order “Replace everything related to commandprompt with powershell by default” and this got included.
Replacing it in the Win+X menu and Shift-Rightclick has been an option for a couple of years now and I can understand why they want to switch PowerShell to the default. I am going to have to change it back to cmd.exe until I figure out how to give “real” cmd commands to PowerShell though (like dir/a/s/b/on *20161121*.log)
I like having the choice of using the simplistic cmd
and then having the power of powershell….
One major point of cmd, it just works. its fast enough for what it needs to do, and doesn’t have a lot of overhead. Powershell seems to be more powerful, but albeit a tad slower for some simpler operations. Yes, a decent tradeoff, but one i’d rather not take sometimes… just my opinion
Another reason I’ll never upgrade to Win10 (if spying wasn’t enough) – and when Win7 shares WinXP’s fate in terms of support I’m switching back to Linux (or sooner than that, if Unity3D moves their… assets and port Unity Editor to Linux officially, not as potentially unstable beta).
Gag me with a spoon.
Accept the money.
Don’t accept one line of code though from them.
As we all know, Microsoft products cause cancer.
It just isn’t safe.
😉
https://fishshell.com
The reality is bash is based of standard old unix world shell script. Bash was not designed for user-friendliness because the shells it was designed off were not that user-friendly.
Of course that does not mean there are not shells like fish shell that were designed for user-friendliness to hand hold a person the complete time they are using it.
Why were the old unix shells so unfriendly is that they were designed for terminals where once you sent stuff to screen that was it the line would print and it would be moved up a line. That is not a highly user interactive thing. Shells like fish take the fact that you can do interactive.
Then you get something like powershell that all round nightmare because commands change based on what extension is loaded.
Please correct me if I’m wrong, but it seems to be incompatible with cmd, so almost every batch file I have, has to be rewritten for it.
Just a horrible idea!