Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Microsoft Windows

Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build ( 280

Bogdan Popa, writing for Softpedia:The latest Windows 10 insider build brings a change that puts the Windows PowerShell in the spotlight, as it replaces the super-popular Command Prompt in some essential parts of the operating system. 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.
This discussion has been archived. No new comments can be posted.

Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

Comments Filter:
  • Don't forget... (Score:4, Informative)

    by Pseudonymous Powers ( 4097097 ) on Friday November 18, 2016 @10:50AM (#53313893)

    Every time you open a command prompt, don't forget you have to enter "set-executionpolicy unrestricted" before you can actually run anything.


    • Re: (Score:3, Informative)

      by Anonymous Coward

      or you set it globally, once, and you're done with it

      • or you set it globally, once, and you're done with it

        Interesting, if true. However: command text or it didn't happen.

        To be honest, I've never messsed with PowerShell much, because previously, cmd, you know, was there, and, you know, works fine.

        • Re:Don't forget... (Score:5, Informative)

          by FreelanceWizard ( 889712 ) on Friday November 18, 2016 @11:19AM (#53314171) Homepage

          Open Powershell as administrator and type:

          set-executionpolicy unrestricted -scope localmachine -force

          Alternatively, set it through Group Policy (Policies\Administrative Templates\Windows Components\Windows Powershell\Turn on Script Execution, set to "Allow all scripts").

          • Re: (Score:2, Troll)

            by lgw ( 121541 )


            Now MS has reached the level of usability of naming commands intuitive things like "grep", only with lots more typing.

            • You can always set aliases for any cmdlet. There are many aliases which come out of the box with PS. For example: wget is the default alias for Invoke-WebRequest

              I personally like the verbosity of the commands. Of course, I am always the guy who uses the logopts in Linux commands anyway (--verbose).

              Besides, if you are using the ISE or the PS console, you can tab complete the cmdlet names as well as the arguments so it is not a lot of extra typing.

              • Re:Don't forget... (Score:4, Insightful)

                by lgw ( 121541 ) on Friday November 18, 2016 @12:09PM (#53314641) Journal

                You can always set aliases for any cmdlet.

                Which does wonders when sharing scripts with your team/friends.

                Heck, think of this in terms of what you're going to have to repeat 3 times over the phone to elderly relatives. (OK, I just tell them "get a Mac" and then "oh, I know nothing about Mac, try my brother", but my solution may not be general.)

                • This is such an old complaint. These days you send your relatives (especially your relatives) to the very friendly Windows telephone support folks who called you the other day.

                  Win, win. So to speak.

          • Serious question...

            Starting with Windows 10, I've found that Microsoft seems to reset a lot of security preferences with every single windows update that runs. Case in point: UAC. It turns back on each time.

            Does this stick around past an update?

      • by Creepy ( 93888 )

        Opening powershell scripts global execution policy all the time seems dangerous, kind of like running as root all the time. I recall scripting that in a bat file or something and running the bat as administrator (to do powershell installs on Windows 10 beta), but it's been a while. I've been on web dev for the last year and a half, so that stuff is long behind me.

    • Every time you open a command prompt, don't forget you have to enter "set-executionpolicy unrestricted" before you can actually run anything.

      If by "anything", you mean unsigned scripts, well, sort of. Just running commands interactively doesn't require this at all.

      As has been explained elsewhere, it's a one-time thing per account, and can be administered globally in multiple ways.

      • by tepples ( 727027 )

        If by "anything", you mean unsigned scripts, well, sort of.

        Then how do you sign a script without paying hundreds per year to the CA racket? Last I checked, code signing had no counterpart to Let's Encrypt or even an affordable Comodo reseller like SSLS.

        • If by "anything", you mean unsigned scripts, well, sort of.

          Then how do you sign a script without paying hundreds per year to the CA racket? Last I checked, code signing had no counterpart to Let's Encrypt or even an affordable Comodo reseller like SSLS.

          1} You don't. I'm not a dev, but I'm pretty sure you pay to sign your code if you need it signed. It's interesting. On a platform I administer and the right and need to run scripts on, I have the ability to temporarily or permanently permit unsigned to code to run. On systems where I don't have the ability to set execution policy, what business do I have running arbitrary unsigned scripts?
          2} More importantly, my point was that using interactive commands doesn't require changing execution policy.

          • The four execution policies [] are no scripts (default), only scripts signed by trusted publishers, only scripts created locally or signed by trusted publishers, and all scripts. But in practice, most individual developers distributing scripts to the public through GitHub aren't going to be able to afford the CA racket. Nor will they be able to simultaneously satisfy CAs' private key nondisclosure requirements and GPLv3/LGPLv3 requirements for "Installation Information". Thus most scripts distributed through p

  • by Anonymous Coward on Friday November 18, 2016 @10:50AM (#53313895)

    If they get rid of COMMAND.COM, I'm going straight back to CP/M.

    • Will the DOS commands I so know and love still work under POWERSHELL.EXE? If I type CMD in the search panel in the taskbar, will POWERSHELL be what pops up?
      • The vast majority of the commands are aliased so that they do work. However, the switches and options for the commands are all messed up. dir works fine. dir with any options does not. (same for ls) There are some edge cases where you'll have to put .exe in so it knows what you want. I use sc (service controller) from cmd all the time, but in Powershell that's the short version of Set-Content, so If I want to use it in Powershell I have to specify sc.exe.

        • So dir /w/p won't work? Okay. What about if I type 'help'? Will I get the full list of PowerShell commands?
    • If they get rid of COMMAND.COM, I'm going straight back to CP/M.

      Spoken like a true, future focused IT professional willing to learn new things.

      Or, you know... not.

    • by hAckz0r ( 989977 )
      8080 > PIP C:COPY.COM=C:PIP.COM

      Gates: There, fixed it to work better! (CP/M ==> QDOS Quick and Dirty OS, aka. PC-DOS).

      IBM: Well, except all the arguments are all backwards. How do we ever fix that? How will we ever sell this thing? Nobody will ever figure out how to use it now...

      Gates: Easy, I'll write a contract to force everyone to buy a copy along with the machine. Just like selling a car with an engine.

  • by Anonymous Coward

    Just because it's been around for a long time doesn't mean it's popular. Thank goodness for cygwin and bash.

    • It may not be popular but people know it. We've got over three decades of using those commands and that interface. If all cmd commands work, great. If not I foresee many complaints.
  • ... they'd just replace the command shell with the linux bash shell they just added!

  • by Snotnose ( 212196 ) on Friday November 18, 2016 @10:53AM (#53313935)
    they can do whatever they want to the command line.
  • by guygo ( 894298 ) on Friday November 18, 2016 @10:54AM (#53313937)
    I see bash for Windows becoming a lot more popular in the near future.
  • by slaker ( 53818 ) on Friday November 18, 2016 @10:59AM (#53313993)

    I know Powershell and it has been around for a while now, but it's almost always less mental effort on my part to string together shell commands than to open the Powershell ISE and read up on keywords and object attributes. It's habit, but I'd rather keep the thing I'm used to. I know bash scripting and perl too and I can be productive in perl but it's almost always faster for me just do what I need with bash, so I suppose the analogy is similar.

    • Yes, I've learnt a lot of languages and syntaxes over the years so I know I'm capable of learning powershell too. That said, working with command prompt has always been second nature to me over the last few decades. Adjusting will be a little awkward.

    • I tend to agree.

      When writing Windows scripts I always ask "Can I accomplish this with a simple batch script?" If no, I then move on to PS.

      So, I have a lot of batch scripts out there. I would hope that explicitly calling the cmd.exe would still execute the actual cmd shell. If not, this will almost certainly break a lot of existing stuff. But MS would, of course, know this...

    • I honestly think it's worth getting some passing familiarity with Powershell. If you're just running one-off commands, then most of those commands will still work in a Powershell window. If you're scripts to do much of anything, you can do more, better and more easily, once you get used to Powershell.

      I'll grant you it's a bit of a learning curve, but it's worth it.

      • If you already know Perl, it is pretty easy to pick up PowerShell. There are enough similarities that it makes it seem familiar. At least that was my experience.


        PowerShell: function myLog{ (Get-Date).ToString() + ' - ' + $msg | Out-File $logFile -Append }

        Perl: sub myLog{ open (LOG,">>$logFile"); print LOG `date`, ' - ', $msg, "\n"; close LOG; }

        PowerShell: if ($something -eq 1) { Write-Host "yes" }

        Perl: if ($someThing == 1) { print "yes\n"; }

        PowerShell: foreach ($thing in $things) { Write-Host

  • by Anonymous Coward on Friday November 18, 2016 @11:00AM (#53314011)

    Microsoft registered [] for a reason, people!

  • There are a few 3-rd party tools that will add items.
    I can't see them removing cmd.exe altogether

    As for adding items to the Explorer context menu, that is just a matter of editing the registry.
  • by Anonymous Coward on Friday November 18, 2016 @11:07AM (#53314051)

    I love Powershell, but half the "admins" I've worked with still don't know how to really use it. It's not an enhanced command or command+, it's a completely different product that unfortunately looks similar enough that non-technical people are going to have no frigging idea what's going on.

    This is going to cause a nightmare for call center staff who all have scripts that say something along the lines of "Open a command prompt and ...".

    • by guruevi ( 827432 )

      The problem is we don't need a Python-esque shell for C#, us admins just need to be able to run "ipconfig" and "shutdown -r" on a Windows box and perhaps the command to re-register the freaking serial code every other month.

      • by Junta ( 36770 )

        Of course, it's not python-esque, it's much worse. It reminds more more of javascript or perl, but with less power than either in terms of syntax (yes, feature wise you can access all kinds of .net functions, but structuring your pure powershell is very limited and the syntax can be very hard to maintain).

    • I think Microsoft should make an offline PDF manual available w/ the next update, which one can pull up if one needs to look something up. Accompany that w/ an online help if one wants to know WHICH powershell commands to use to fix something, such as, say, the number of rows of icons in tablet mode on a small tablet, if one wants >4.
      • Make yourself familiar with the help system in PowerShell. Just like any decent Linux admin should be adept with man, any decent Windows admin should be adept with Get-Help.
  • Well, this will be a fun surprise for millions of people running command-line tools. Maybe that'll be my retirement career: "converting" CLI instructions and tools to the new world in Windows 10+.
    • PowerShell is older than dirt. Nothing new there. I work in government IT and we use PowerShell on Windows 7. I personally would like to use Python but that's not on the approved software list.
  • by DrXym ( 126579 ) on Friday November 18, 2016 @11:18AM (#53314155)
    The normal command prompt is simple, stupid and does what it's told. Powershell is like some esoteric, incompatible, overly complex thing that claims to do anything via cmdlets, scripts, functions etc. but ends up just complicating everything including the simple stuff. It doesn't even have the good grace to be a superset of command prompt or bash which would at least make it familiar.

    I don't see how forcing people to use it is supposed to win people over or fail to piss off people who want the old command prompt.

    • Out of curiosity, have you ever opened powershell and started issuing dos/cmd commands?

      Here's a hint: works great. Powershell isn't a superset of cmd, but it implements cmd commands. You can likely take a .bat file, rename it to .ps, and have it run just fine. I've never had a problem doing so, at least.

      This is kind of like complaining that your Linux distro is replacing sh with bash; all your old stuff will keep working, but now you have new options and abilities that you can slowly migrate to.

      • by DrXym ( 126579 ) on Friday November 18, 2016 @11:43AM (#53314351)
        You can't issue dos/cmd commands. The likes of "dir" are aliases onto things in powershell which superficially resemble the old commands but function differently.

        For example I can type "dir", but "dir /?" doesn't do a thing. So maybe the syntax is a bit different. Typing "dir -help" or "dir --help" issues an enormous error message that apparently I've done something wrong. Not helpful. Typing "help dir", tells me about something called "get-childitem" but essentially doesn't help at all except tell me to type "get-help Get-ChildItem -detailed". Eventually I get a wall of text which STILL doesn't correspond to the old syntax.

        Would it have really killed Microsoft to make "dir" function like "dir"? Maybe later on when I'm comfortable and familiar with the powershell I might want call get-childitem for something. But it is FAR more important to me during transition that the thing is familiar and all the various .bat / .cmd scripts that I have actually survive the transition.

        I should add that the command "ls" also aliases to "get-childitem". So Microsoft are equal-opportunity confounders.

        • You could try making an alias that gets detailed help. Call it man.

        • If you're using cmd in 2016, chances are you don't need help using the 'dir' command.
          • by DrXym ( 126579 )
            My point if it wasn't clear was there was no reason for incompatibility in the first place. If "dir" can be aliased to something called "Get-ChildItem", then it could have been aliased to something called "Get-Dos-Dir" which implemented the same arguments and behaviour as the CMD dir. The same applies for the other commands built into CMD - popd, pushd, cd, goto, if etc. plus any syntax for environment variable expansion, pipes, redirection etc. Even invoking the command "cmd" itself could have been impleme
        • I mostly agree with you, but to me, the major problem with PowerShell is that it's basically a REPL for a C#-like programming language. If I wanted to write C#, I'd launch Visual Studio.

          Take the GetChildItem and error message reportage you brought up. The fact that "dir" is implemented in terms of GetChildItem and it's easy to discover that accidentally is a *good thing*, the same sort of thing that so many of us geeks used to praise Smalltalk for. The real downside here is that PowerShell errors are basica

      • by bdh ( 96224 )

        Out of curiosity, have you ever opened powershell and started issuing dos/cmd commands?


        Personally, I don't use either PowerShell or command shell, much preferring JPSoft's far superior Take Command [] to both of them. However, when I have had to use PowerShell, I've often used the "help" command, which is markedly different from the command shell's.

        In PowerShell, type "help" and then type "cmd /c help" and see the difference. For those who rarely use the command shell, switching to PowerShell will not make life simpler.

        • by Wolfrider ( 856 )

          +1 for jpsoft. From the first time I used NDOS from Norton Utilities, then moved on to 4DOS, I *instantly* preferred it to "" and "CMD.EXE". Left it largely behind when I went to Linux as my primary OS, but still install it on all my Win7 legacy stuff.

          The free version is called "tcc/le" on the site and there is also a 64-bit version "tcc/le x64".

          Hopefully he will get more business from this (yet another!) asinine decision by MS, they have been really overtly stupid since Win8 came out and are c

      • by tepples ( 727027 )

        You can likely take a .bat file, rename it to .ps, and have it run just fine.

        Wouldn't that try to render a page in a PostScript interpreter and then send it to the printer (or vice versa, depending on the printer model)?

    • Its built-in linux-like commands don't appear to work as expected, I guess due to aliasing. "ls" is fine. But with any arguments, and I get stuff like this:

      PS C:\mingw\bin> ls -l
      Get-ChildItem : Missing an argument for parameter 'LiteralPath'. Specify a parameter of type 'Sys
      At line:1 char:4
      + ls -l
      + ~~
      + CategoryInfo : InvalidArgument: (:) [Get-ChildItem], ParameterBindingException
      + FullyQualifiedErrorId : MissingArgument,Microsoft

  • by Anonymous Coward

    On my current Windows 10, there's no less than 4 different PowerShell version that I can invoke, and presumedly they work different, and a script may or may not work depending on what PowerShell you invoke. Is this how it's supposed to work?

  • by ErichTheRed ( 39327 ) on Friday November 18, 2016 @11:41AM (#53314339)

    As a long-time Windows admin/systems guy, I think it's definitely time to do this. The batch language is very easy to use for procedural scripts, but in the world of things like desired state configuration, API-driven everything, etc. it makes sense to have a scripting language that basically makes the same calls a compiled program would.

    I think the two major drawbacks that are presenting a learning curve are the syntax and the "scripting Legos" aspect. Syntax is...interesting. I have tons of cross platform experience so I have good understanding of lots of command languages. PowerShell's syntax is like DCL (the OpenVMS script language,) Bash and Perl got together and had a 3-parent baby. It's extremely verbose a la DCL, yet extremely symbolic like Perl, and has Bash-like constructs in there as well. Once you get used to it it makes sense, but there's definitely some learning before you're proficient enough to write full redistributable tools in it. The other thing that puts a lot of people off, but that's actually great about it, is that commands don't output text and you have to think things like object types. Bash, batch files or VBScripts have to include tons of logic to parse output, read/write INI files or XML data, etc. That gets reduced to a single statement -- want a CSV of the output? Export-Csv replaces tens of lines of function code to open a file, construct the strings and write them out. It's awesome but very different from the craft-your-own days....just like writing modern software, it's just gluing someone else's code Legos to each other and interfacing with APIs. It's hard to tell what you should be writing and what is already written for you and you're just assembling if you're used to building it all yourself and manipulating stuff with sed/awk/grep and friends.

    That said, it's definitely time for Windows admins to get on board with PowerShell. Admins that survive the next transition are going to be managing thousands of servers or microservice instances at some IT provider. You can't manage systems at that scale by manually connecting to them and tweaking things. It's the same thing with Microsoft's Azure service -- it's been developer focused from Day 1, and admins are just now getting documentation that's even somewhat tailored to their experience. I know DevOps is the cool new buzzword, and every admin should have some basic coding skills under their belts, but it's hard to take someone who's been taking care of systems and telling them to treat them like software deployments. This is going to be the next big leap for systems guys now that software defined everything is pretty mainstream.

    • Powershell is a shitty scripting language, but it's the only one that puts all the admin capabilities I need under one roof, so I use it. But I loath it intensely, and wonder why kind of idiots would build a language like that.

  • by Dwedit ( 232252 ) on Friday November 18, 2016 @12:02PM (#53314571) Homepage

    So much for compatibility.
    In powershell, you can't type in "cd\directory".
    Not to mention that any shortcut to "CMD /C" or "CMD /K" will break overnight.

    • On the bright side, PowerShell has alias for most commonly used Linux shell commands. I'm always typing in ls instead of dir for a directory listing.
      • by Dwedit ( 232252 )

        You get linux-like commands with Cygwin or Msys, so ls will still work from the command line.

        Unfortunately, creating any cygwin process adds over 1/3s of startup time, so commands called by scripts like ./configure that should be instantaneous are slow instead.

  • I can only assume this is Microsoft's final attempt at killing off the command line. So much for hoping one day they'd actually provide a usable one.

    If they really wanted to provide an enhanced, programmable shell, then provding a good, lightweight programmer's editor would be the first step. As it stands, Notepad doesn't even recognize Unix style line endings.

  • by JustNiz ( 692889 ) on Friday November 18, 2016 @01:20PM (#53315339)

    "you'll only be allowed to launch the more powerful app"

    Hey Microsoft, please remind me: who owns my PC?

    • by Wolfrider ( 856 )

      ...If you REALLY want to own your PC, you don't run Windows. But take a look at as mentioned above, they have a free CMD replacement called tcc/le.

  • it replaces the super-popular Command Prompt

    Super-popular? That's pushing it.

    Most people pay tax, but that doesn't make it super-popular.

    so Microsoft has made a significant step towards phasing out the traditional Command Prompt.

    Everything said before this indicates they've completely replaced it. I'd say that's a fairly significant step, I guess.

  • I just opened power shell and typed the number one most common thing I type at the cmd prompt: "putty @session" and it opened the putty configuration window rather than launching an ssh connection to the designated server. That's a non-starter for me.

Some people have a great ambition: to build something that will last, at least until they've finished building it.