Hacker News new | past | comments | ask | show | jobs | submit login
Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build (softpedia.com)
392 points by ctoth on Nov 18, 2016 | hide | past | favorite | 342 comments

Btw did anyone noticed that in windows 10 you can resize cmd.exe to more than 80 characters width! When I first saw it I almost cried.

IIRC you could resize the standard cmd console easily, just type "mode 160" (or whatever width you want). I don't have a Windows installation around to check it, but maybe someone can confirm?

Yes, that is correct.

Display mode: MODE CON[:] [COLS=c] [LINES=n]

Hey!!! This works in PowerShell (non-ISE)!!!! Breaks my 112 column limit, despite a default setting of 200.

Added this to the end my Microsoft.PowerShell_profile.ps1 in my $HOME\Documents\WindowsPowerShell directory. (run: "notepad $PROFILE" in PS)

  Clear-Host (I get some artifacts)

All functionality used to reside in conhost.exe, no matter which character mode application you used (command prompt or PowerShell), which is why a lot of commands would work for both character modes. This is not how things work now (though a lot of commands are still shared, like “mode 120,120”) as conhost.exe now just decides if it should give you the legacy console host or the new one (with things like buffer improvements and word wrapping).

There are a lot of subtle improvements I think many are not aware of, like, if you paste in text with smart quotes they will be changed to straight quotes.

One of those subtle improvements is honoring a Ctrl-L. I like to be able to clear the screen like that.

TIL. Thanks very much.

You could also previously use the console properties page (accessible from the system menu of the console).

Huh. Apparently yes. I think I'm in love with you now. Carry on.

And you can use Ctrl+C Ctrl+V :) If you upgraded from a previous Windows you need to disable legacy mode.

Thanks for this. I upgraded and was wondering why I couldn't Ctrl+C/V vs one that was a fresh install.

So no Ctrl+C to bail out of apps? Is there an equivalent?

most of the other shortcuts don'T work though.

i miss ctrl-d for example

Most Windows terminal people use ConEmu rather than the inbuilt terminal apps - it's like iTerm2 vs Terminal.app on MacOS. ConEmu adds Unix style cut and paste, tabs, etc. Add openssh, PSReadLine and PSCX and you've got a proper terminal setup.

Also MS should really improve the inbuilt apps to do this stuff.

I've used iTerm and Terminal on Mac, and the default Windows Terminal (conhost), PuTTY sand MinTTY on Windows.

Terminal.app is much, much better than conhost, even after the Windows 10 update. It's fast, supports a ton of thoughtful features (such as customizable title bars via extended ANSI codes, real line wrapping during resize, good Unicode support from the very beginning, etc.). With Terminal.app I can be quite happy and productive even with someone else's Mac or with the default settings. I've used iTerm2 but their features weren't compelling enough for me, and the iTerm font rendering is noticeably worse in many ways. Apple has also been very good about giving Terminal.app continuous updates.

On Windows though I have almost always had to install MinTTY or something just to get a halfway usable terminal emulator. The default emulator is just so limited - Unicode support is very plug and pray, the title bar is totally locked, and having to use Windows APIs to change text formatting is a pain. Conhost is also amazingly slow when it comes to large amounts of text, so much so that printf can be extremely detrimental to program performance just because it has to wait for the terminal window to catch up.

PowerShell's terminal experience is better but not quite there. And, PS suffers from extremely long load times - I've seen it take upwards of 10 seconds to start without any extensions. That means that in practice I often pop open cmd.exe even if PS is a better choice, just because I don't want to sit through a long load time.

Microsoft really should get their Terminal story in order. I'll definitely try out ConEmu the next time I sit in front of a Windows box, but like you I wish MS would improve their own apps!

> good Unicode support from the very beginning

I once started a Chinese character flash card program in Python on Windows.

The yak shaving was unbelievable. I never got a working version, but I learned a lot about code pages, and why "building a console from scratch" is not actually the right answer to "I want to be able to test a toy program I'm making before it's finished."

Tkinter would have given you a basic Unicode capable GUI without the hassles of the console.

Hmm, going back through my old .py files, I ultimately did start using Tkinter... and for some reason thought yaml was really important...

Still, would have been nice to have a program that essentially took in and put out text without learning everything about GUI elements.

I'd never written anything with a GUI before, and "I'd like to see unicode" is a really weird place to dive in.

> PowerShell's terminal experience is better but not quite there. And, PS suffers from extremely long load times - I've seen it take upwards of 10 seconds to start without any extensions.

Small price to pay to be able to pipe objects, man!

Sorry about that - we lost control of our startup times in PS V3 and have been working to get it back under control. PowerShell V5 had substantial improvements but we keep working on it and V5.1 is even faster. Give it a try - I think you'll like it.

Jeffrey Snover [MSFT]

I really hope so!

I basically stopped using ps ( for smaller stuff) because the startup tone is so awful.

I'm not entirely sure if you're joking or not (one of the hazards of the textual communication medium). Yes, piping objects is fun and occasionally very useful, but waiting ten seconds to pop a terminal so I can run `ipconfig` or something is not so useful.

Are you actually able to not be confused by piping objects? In Unix everything is a string so I just pipe text to sort and then unique...etc. PS always complains relentlessly. The GUI features and .NET integration is nice though.

What drove me away from Terminal.app was the fact that I can't use command-1/2/3 to switch tabs. Ctrl-tab doesn't work either.

Did I miss something?

CMD + { and CMD + }

Thanks but... yuck. Any way I can remap these?

Cmd-<number> is a pretty standard way to jump to tabs (and arguably, Ctrl-tab as well).

⌃⇥ actually does work in Terminal.app. And in fact, ⌃⇥ and ⌃⇧⇥ are the official keyboard shortcuts in the menu, with ⌘{ and ⌘} being undocumented aliases. This is also how Safari works too.

I wonder why they chose ⌘{ and ⌘} instead of ⌘[ and ⌘]. With the later you don't need to hold down SHIFT (at least on US keyboard layout.)

Because it's the same keyboard shortcuts that Safari uses, and in Safari ⌘[ and ⌘] navigate the history stack.

Whilst I am glad to hear about ConEmu; I have to disagree, I use windows cmd.exe very regularly, and know lots of other people that do, and I have never used ConEmu before! I might give it a try now I know about it.

Cmder is a good configuration bundle for ConEmu and a better place for new users to start.

Cmder seems cool but it's ConEmu + Clink + git for windows.

- Clink is for cmd what PSReadline is for posh.

- posh-git does what git for windows does (I personally don't like git info in my prompt, so use neither, and have a custom, Unixy-one)

ConEmu si really nice simply because you can have tabs, split pane and good color schemes. 've never gotten to the level that some people need, so ConEmu + bash = everything I was using on OSX.

I highly recommend ConEmu, I've used it for awhile.

con emu makes the linix subsystem shell a lot nicer too, in fact has an inbuilt ubuntu theme that makes most colors sane

I use Windows since version 3.1 and never bothered with it.

Properly configuring cmd.exe was enough for me. Then again I only use the terminal on "as required" basis.

It has never been stable for me, so I stick with the console, even though I would like to switch to something better.

My work laptop still runs Windows 7 - and will for the foreseeable future - but that is one of the things that make me curious about Windows 10. It is, of course, easy to ridicule Microsoft for how long it took them to change this, but I think better late than never.

(On older versions of Windows, ConEmu[1] does that, too, but it's third-party software, of course. It also supports tabs!)

[1] https://conemu.github.io/

Since conemu is mentioned, I'll chimed in with cmder[1]. It builds ontop of conemu and has git-for-windows integrated as well.

[1] - http://cmder.net/

cmder developer also says:

> If you have trouble with anything I am happy to help. But you will have much better chances to find solutions on the pages of the upstream projects. Those are:

    Console emulator ~ Conemu (https://conemu.github.io/)

    Cmd.exe enhancements ~ clink (https://mridgers.github.io/clink/)

    Unix tools on windows ~ git for windows (https://git-for-windows.github.io/)

Thank you very much! I'll give that a try!

I've been able to do that in versions of Windows going back as far as I can remember.

Correct me if i am wrong, but all i remember is you could edit the width somewhere in the options. But there was no way to change the width _on the fly_ (assuming thats something it does now)

Older versions could resize the window with a drag, but the underlying buffer required a menu option, which was very awkward.

In Win10, you can resize the buffer with a drag as well.

They made the option easier to find.

I don't remember ever not having that feature, so it must be around ever since XP. Right click window -> Properties -> Layout.

OP means you can drag the window wider - no need to alter properties anywhere ;)

Drag-resize (affecting buffer, as well) is nice, finally. And you can change opacity in properties, making your window transparent.

What I really like though: you can now use Shift + arrow keys to select text and C-c/C-p to copy/paste.

If you're going to use CMD/PS on windows you might go whole hog and install ConEmu. Then load it up with Cygwin, and DosBox.

ConEmu can even integrate stuff like Putty.

Thanks for that suggestion. I am well aware of these options, and if I used Windows at home, I could utilize these. However, I only use Windows when I have to, which is at work. The environment in which I work, you can absolutely not install software like this, as you would be breaking security protocols (and the law).

So this explains the joy I feel over small improvements like those mentioned above.

> ConEmu can even integrate stuff like Putty.

If you're going to use ConEmu, just go ahead and use the straight & regular OpenSSH command-line ssh tool.

Then you get all the standard niceties you can stash away for global reuse in ~/.ssh/config.

I don't miss PuTTY one bit.

Ooh, could I use this to get ECDSA keys with configurable rounds of hash functions?

I might switch from putty to ConEmu with OpenSSH then. Presuming I can get ConEmu's look close enough to my putty.

ConEmu is endlessly modifiable. You can inject dll hooks into it if you so wish even.

You could do it at least in Win7, maybe earlier, do not have anything older to test with. Click on icon (right click on top bar) --> properties --> layout. You can edit both window size and buffer size

It also support transparency and lot more features. Install sysinternals, chocolatey (a package manager, https://chocolatey.org) and python, you are good to go.

You could do this since at least XP!

You just needed to go in to the properties of the window and increase the screen buffer size (both width and height). It's one of the first things I'd do upon installing a Windows machine.

I have been waiting for that for years - now if they would only add TABS to real powershell (as opposed to powershell ISE) or if they can add colors to powershell ISE I will be super-duper-bonus happy.

They have 24-bit colour support in the latest Insider build.

We are incapable of sustained error. 25+ years was enough. :-)

Jeffrey Snover [MSFT]

Alternatively you can use ConEmu[0]


I've found ConEmu's xterm emulation to be frustratingly buggy if I'm ssh-ing into a Linux machine and running tmux, vim, or really anything with colors or a status bar. mintty [1] works a lot better for me. (mintty is also the console that's packaged with Git for Windows.)

[1] https://mintty.github.io/

Lol you could always have done this by setting the command prompt properties -> since at least 3.51 ;)

also CTRL+V pastes by default now, but yea you're no longer locked into half the screen by default. I wonder why that's been like that for so long? Must be some reason...

Console GUI applications. Pretty much any tweak to conhost ever and they'd implode.

I don't know what's changed now but they've rolled that policy away. Maybe virtualization?

They may have decided that the number of people running console programs with a GUI is low enough now.

I don't know whether it still was necessary, but the removal of support for 16-bit applications from 64-bit Windows 7 will not have hurt there.

Aren't we glad it's 2016 ?

Seriously? I wonder how they managed to do that, i am sure that required a whole engineer team for a whole month!


> Every idea for a feature starts out with an imaginary deficit of -100 points. That means it has to demonstrate a significant net-positive effect on the product as a whole in order to emerge as being truly worthy of consideration.

That is actually pretty interesting, thanks for linking!

I still dont understand how this was not "fixed" years ago, sure some config windows have fixed widths because it makes sense, but something as a terminal obviously needs the ability to grow (or shrink), especially after they introduced sticky windows and people actually used "tiling"

The idea that the console screen is an MxN matrix is pretty embedded in the API... it's not a MDA display adapter metaphor, not a Unix-style typewriter. I'm guessing they just felt they had bigger fish to fry.

(Everybody I know that uses the console window a lot has always just set the window to 120x9999 or 160x9999 or whatever and forgotten about it. It's one of those things that's obviously kind of lame, but after a while you just forget about it.)

Odd, I've always set it to 132.

Oops... it IS a MDA metaphor!

That's nice. Can you pipe binary data without powershell corrupting it, or is that now a feature?


It's amazing, isn't it. They went to the effort of building a typed shell but didn't realise there are multiple different types of string.

I bet it still truncates output of the ">" operator to the console width, too.

    'troll' * 1000 > out.txt
Open in NotePad++, no weird newlines in the wrong place, content not truncated.

Were you using |format-table and |format-list (ft, fl) to explicitly format the text for console viewing, then redirecting that to a file?

Took a while to reproduce the actual case, and it's Select-String that's at fault. And it must be in "powershell" not "powershell ISE".

  'troll' * 1000 > troll.txt
.. works fine as you say

  Select-String -Path .\troll.txt -Pattern "t" > t.txt
.. wraps the output at the console width. Which means you can't use it as a grep replacement.

You can't use it as grep in bash, because it isn't that. It outputs [MatchInfo] objects, not text, and Out-File (>) formats complex objects for console viewing (for ??? reasons), which is one reason > isn't a great PS habit.

    Select-String -Path .\troll.txt -Pattern "t" | Set-Content t.txt


    sls 't' .\troll.txt | sc t.txt

this ^^^

This is the main reason I still use cmd.exe

Related, running something like decrypt hugefile.dat | encode outfile.dat will usually result in powershell using up all your system ram and crashing.

On a somewhat related note, one of PowerShell's biggest weaknesses is memory utilization. And since they make it so simple to pass around hefty object collections it tends to bite you in the ass early on. Particularly when you're using cmdlets. When doing real scripting that actually needs to be run as a job I am surprised when I can get away with cmdlets and don't need to manage .net APIs/objects directly. Especially third party cmdlets.

One performance tip I picked up early on: If you're passing around large object sets you need to operate on try to keep them in a pipeline. Populating a variable and interacting with it is arguably more readable and maintainable, especially for junior people, but it has a heavy cost in terms of memory.

That said every version of posh is better than the last so I may be wrong or overestimating the impact for the newest versions. YMMV, don't believe everything you read on the internet, etc.

That is a good tip. There are certain product teams that produced ENORMOUS objects and your suggestion helps when dealing with that.

Jeffrey Snover [MSFT]

Upon reading that again maybe I should have said it's weakness is that it's easy for everyone involved to create objects that use a lot of memory. I'm not sure it's fair to say PowerShell itself is bad at utilizing or managing memory. It's more of a possible negative side effect of one of its great strengths.

That's great advice, man. Cheers.

Most likely because it loads it all into memory, rather than say streaming it.

That's how I would expect MSFT to build it.

This bit me badly when trying to pipe GPG output. I ended up building a command string and sending it to cmd. :|

That is odd, powershell shells out to cmd.exe if you try to pipe binary or text data. It goes back to powershell only if you use powershell commands in the pipeline.

If you don't pass the flags zo handle it as binary in those cases stuff breaks.

I found out yesterday that `Select-String`, PowerShell's "grep equivalent" expands tab characters to spaces.

Haven't tried in the preview build but this is still the case in the recent Windows 10 build I have.

Powershell drove me to Mac

Get-Content test.jpg -Encoding Byte -ReadCount 1000 | Set-Content test2.jpg -Encoding Byte

Piped binary data, not corrupted, since a long time before that blog post was written.

What you can't do is run native commands, and read their standard output as a byte stream without going through .Net and Start-Process.

Was super fun to learn about this when restoring the "backup" dumped via pipe in a powershell script.

While the first rule of backup is "do them", the second rule is "test them". If your backups are bad and you only notice it when it's time to restore, you only have yourself to blame.

"The backups fail to restore" is such a common occurrence, it's really scary.

Something that irks me is how PowerShell’s default aliases take precedence over binaries in the PATH. To be able to use the GNU utils, you have to put this in your profile.ps1:

  Remove-Item Alias:cat
  Remove-Item Alias:cp
  Remove-Item Alias:curl
  Remove-Item Alias:echo
  Remove-Item Alias:ls
  Remove-Item Alias:man
  Remove-Item Alias:mv
  Remove-Item Alias:pwd
  Remove-Item Alias:rm
  Remove-Item Alias:wget

Isn't that always the case, that shell built-ins take precedence over things elsewhere in the system? On Unix you have to call them with their full path, e.g. to get the system echo instead of bash's you need /bin/echo, I guess. On Windows you can add the extension, i.e. use ls.exe instead. Even cmd shadows programs that have the same name as a built-in, e.g. echo.exe must be called as such and just echo will use the built-in command.

That is correct. Most people do not notice because the buildings in bash are almost completely equivalent to the standalone binaries.

I've only ever really noticed with 'time' and 'echo'

I have noticed this with echo too. In specific, the bash echo built in does not drop support for -n and -e when bash is forced into standards compliance mode as /bin/sh. That causes breakage on systems that use more strictly compliant shells when code was written against bash as sh under the assumption that either -n or -e work. I spotted a regression in Linus' tree a while back where this very thing happened in the build system for perf. Sadly, my patch to fix it was ignored:


If it is still an issue you want to fix, you may need to resend the patch periodically. It doesn't look like you got any response at all.

LKML gets hundreds of messages every day. When I used to read it I had a set of search filters to prioritize it. Anything I didn't get to I simply marked Read. There's no way to catch everything on there.

Maybe get it passed through by someone who is in Linus's email filters.

Although it's been a year and you probably don't care anymore. :)

The time builtin is often less functional than the /usr/bin/time and does not have functionality like the -v parameter.

"command echo" instead of just "echo" should bypass the shell builtin.

How would an alias work otherwise? That's pretty much the way it behaves in Unix, too (e.g. 'ls' in most default configs).

Although I'd still consider curl/wget to be specific tools and not generic commands, so emulating them seems a bit weird.

The point is that they're defined by default. See this story for more background:


Edit: the RFC intended to address the curl author's issue was rejected.


Yeah, because it would represent a breaking change.

There are use-cases where globally removing aliases isn't an option (e.g. scripting for use on a machine that isn't yours).

For those, it's also possible to evade the aliasing just by explicitly appending the .exe onto the command. 'pwd.exe' gets you the GNU version.

Wait, the Linux subsystem on Windows inherits that stupid convention of deciding if a file is executable by its name?

No, this is in powershell not the linux subsystem. In powershell they defined a bunch of aliases to internal powershell functions like cp, mv, cat ... that don't work like the original unix version. If you install the GNU version on the system and try to use them in powershell that won't work by default. You either remove the alias or use the trick above to force powershell to use the .exe of the utility.

Oh, ok. That was GNU tools compiled for Windows, not the Linux subsystem. I was surprised for a while, but yes, I shouldn't.

No, Windows does not decide whether files are executable by looking at their name.

It's GUI shell does. Theoretically you can create a process from any binary blob. But to invoke it the gui way you need to have it either with an .exe or another self executing ext defined in the registry.

Windows just failed on running my text file because it didn't have the correct header.

"is executable" is different from "is an executable". Your other comment was worded to say the former, while this one seems to refer to the latter.

For example, a .jpg image can be marked as executable, but it is not an executable. This can happen on both Linux and Windows, and I believe it is handled by the filesystem. I supposed the term "marked as executable" could be used for this, while "is executable" could mean the OS will grant it a PID using the correct system call, but this is uncommon.

On Linux, you can attempt to execute any file using a system call like execve(). Similarly, on Windows you can also attempt to run a JPEG using CreateProcess(). I know the Windows shell probably won't run a JPEG even if it is marked executable(there are a collection of Registry entries that map file extensions to programs that run them, for the shell), but I don't know if the CreateProcess() API function rejects files without the correct extension.

If both CreateProcess() and GetBinaryType() fail to detect a PE file with the incorrect extension, then you can reasonably say that Windows uses the extension to determine whether a file is an executable(though not whether it is executable). The behavior of the shell isn't sufficient.

CreateProcess() doesn't care what the file extension is when you pass the executable filename into the lpApplicationName parameter.

I used this feature when I worked on a VR app written in Unity, and I had a little launcher program that checked for updates and then started the main program. I didn't want people to bypass the launcher, so I renamed the main program to have a .VR extension instead of .exe, preventing it from being run directly from File Explorer. The launcher had a .exe extension and could be run normally, and then it used CreateProcess to run the FooBar.VR executable.

Windows has an execute permission, it's just rare for a file's permissions to be set granularly.

The key here is not so much the ".exe" suffix as that it's not "pwd". Think:

  alias some-command='some-command.sh --arg'
and then running "some-command" versus "some-command.sh". (The Window's shell does interpret stuff with the ".exe" suffix differently, just it's not the key factor here.)

That's a bad idea - the inbuilt 'ls' (aka get-childitem - it also works on registry paths) will output real file objects, with properties you can access with 'select' and 'forEach' etc, whereas the GNU tool will output text you'll have to scrape.

I would use `Get-ChildItem` directly in that case. When I use `ls`, I expect it to be POSIX `ls`.

I don't think this is a good default for posh on nix platforms but I would argue that it's a good thing on Windows. The output of PowerShell ls is an object with typed properties and methods that you can interact with in a much richer way.

Not to mention user experience. Adding these aliases made moving back-and-forth between nix and Windows much less jarring for me. They also really helped drive home the difference between something like bash and posh because investigating the differences between the aliases and their nix namesakes revealed their respective strengths and weaknesses.

I imagine changing aliases would be out of the question since they should have priority over PATH but perhaps a special conditional case for these the first time they're run interactively would be to check for the nix equivalent in your PATH and prompt to see if you'd like to remove them.

I don't really het the point of powershell making everything an object. If I wanted that I'd probably be in a python REPL.

I think if you'd asked me a few years ago I might have agreed. But the Python REPL is a terrible shell.

If you have a lot of experience with something like bash and you can run circles with it PowerShell probably doesn't add a lot of short term value.

There was a long argument about this in a thread previously but in my opinion they should not change this now.

The weird thing was that Powershell for Mac doesn't do this.

It's not that weird, they put the alias' in so new admins on windows fresh from linux don't hit a complete roadblock at the first command they type. Its to make powershell less punishing to learn, not emulate a different system.

So imagine when they packaged that for Mac, that assumption is no longer true.

I would argue that for scripting portability, this should be the same. With wget equivalent in Powershell being so different for example, scripts that use aliases will be broken.

Granted, don't use aliases in scripts and all that.

FWIW, I always thought of it as being for portability of humans, and was very grateful for it on Windows. A large chunk of my time is spent on *NIX systems, so my fingers automatically type "ls" and "rm" instead of "dir" and "del". The fact that Powershell worked, rather than throwing a "eh, what?" error made my time on Windows suprisingly more pleasant.

They should have implemented these with a missing command handler. So if the ls wget etc exist they work. But just before the command line complains of unknown program name it should check that list and execute the alias.

A new "bottom of the stack" alias instead of the current one that takes precedent over executables.

They got removed in the open-source version of PowerShell and only remain in the Windows build.

Possibly because by the time the makers put out the Mac version, they were already aware of the issue, and also because the Mac has the GNU coreutils as part of the main OS, rather than being third-party installs, so the problem was immediately obvious to the first tester who actually used it.

"Typing cmd in the run dialog will launch PowerShell as well"

What? I'm a big PowerShell fan, but I see the need to keep cmd around for a while. Clobbering it before it's phased out seems problematic.

Microsoft are taking Apple's approach!


First they came for our 3.5mm headphone jacks, and I did not speak up...

The news article is incorrect. Typing cmd from the run dialog still launches cmd.exe.

The release post spells out exactly what's changes - win-x menu, context menu kind of stuff.

You can run any command from CMD in Powershell

But are all cmd commands portable verbatim to powershell? With all the options / special characters? (I don't know the answer, but https://en.wikipedia.org/wiki/PowerShell#Comparison_of_cmdle... lists quite a few missing commands, including "talkkill" and "find")

With the amount of online posts that tell you "to achieve X, open command prompt and run ...", it would be a bad idea to break any of them that go beyond a simple command. (so for example any "FOR ..." lines)

There can be several aliases for a single command.


But you can't run just run "dir /s". You'd have to say "Get-ChildItem -Recurse" which can be shortened to "dir -Recurse" which can be shortened to "dir -r".

When scripting, you try to use the longform versions. With one-liners, you just sort of fall into whatever paradigm you were previously accustomed to for your first argument.

Such basic commands are actually CamelCase? It must be a pain for those with no short-aliases.

Talkkill seems like a very useful feature to me ;)

You can, but sometimes the quoting rules differ.

For example, bcdedit with its {}-delimited GUIDs breaks in PowerShell without additional quoting, but works fine in cmd.exe. Makes following online instructions tricky if you're not familiar with that nuance.

Well, the nice thing in PowerShell is that you have explicit control over "stop parsing here and just pass the rest to the application verbatim" with --%. Solves a lot of quoting nightmares.

How come none of the tutorials I've read and StackOverflow questions involving Start-Process mention that?


Well, it won't work with Start-Process, and it's also buried deep in the documentation and impossible to google. I constantly forget about the exact character sequence, too.

That's indeed nice. I wonder if there is something like that for ZSH.

I don't know for sure about ZSH and can't test it at the moment, but Bash has -- for this purpose. It may work in ZSH as well.

Isn't the -- a feature of the command to stop option parsing and treat the remaining arguments as file names? AFAIK it's not a shell feature that solves quoting (and it's not that easy on Unix either, since running a program involves argument parsing instead of just passing a string).

You could define `--` as "perform no expansions for the rest of the line", then you wouldn't have to worry about globs or `{}` which is where most of my annoyances come from.

BTW `--` isn't treated specially in version 4 of Bash.

Does Powershell support all my old batch scripts?

Agreed. I like PS too but forcing it breaks a lot of staff, you cant use it interchangeably, eg 2 quickies:

    -bcdedit /c {xxxx-xxx-xxx-xxx} (= {..} is parsed as a code block)
    -invoking executables with spaces in path

    bcdedit --% /c {xxxx-xxx-xxx-xxx}
    & 'C:\Program Files\Foo\Foo.exe'

I know, you could also just put {} around quotation marks and would work. My and parent's point was that it will probably flood MS's support channels, if you just force every cmd user into PS.

Upgrade your staffs ;)

That's not all in latest build 14971.

Cortana supports to do list now

Dial support for map app

Bringing 3D to Everyone via the Paint 3D Preview app (RIP paint.exe, I am going to use picpick or paint.net from now on)

Read EPUB books in Microsoft Edge

Improved Typing Experience with Japanese and Chinese Input Method Editors

New Get Office hub for Windows Insiders









So, while I applaud this, I am concerned about the startup time of ps as compared to the old command prompt. Has it been improved recently?

Funny, that was my first thought as well. Sometimes I start cmd.exe instead of powershell on rotating-disk machines because of the startup time. On SSDs I find the startup time is negligible.

That's my biggest concern, I actively avoid PS just because I can't tolerate its startup time.

It's better but it's still slower than CMD on my computers.

In particular if you have left the prompt window untouched for a few hours and it has been paged out. Just pressing <tab> to complete a file name will hang for 3-6 seconds on my computer while PS wakes back up.

CMD is always instantaneous.

I realize that PS is doing a lot more work to match commands but sometimes simple is all that is needed.

Major improvements in V5.

Even more in V5.1 (which ships with WS2016).

But still slower than CMD.

CMD starts very quickly but then you have CMD. :-)

Jeffrey Snover [MSFT]

Still slower than cmd, fast enough that I'm actively trying to unlearn the cmd muscle memory.

So basically instead of doing

    dir C:\
I have to learn to type

   List-Directory-With-Files Drive=C Folder=/
(made up example, but you get the point)

Both DIR and LS do list directories in PowerShell.

But all parameters on DIR and LS seem to result in errors, even "dir /h", "dir /?", "dir -h", "dir --help", etc. That is a bit annoying.

DIR and LS are both aliases for Get-ChildItem, which doesn't support the flags you're after.

Then don't make them aliases, if they're not the same.

The issue already happened with cURL.

They are aliases for Get-Children. Just like you can have an arbitrary alias for anything on UNIX. If I so pleased I could make an alias so that when I wanted to delete a file I'd type

  emacs some-old-file-i-dont-want.c
Emacs would be an alias for rm on my system.

That being said I think it was quite offensive of MS to use wget and curl as aliases, even though they may have had no ill intentions. I'm ok with using ls and echo and names of other such basic commands as aliases, but with tools like wget and curl that are known for their vast array of useful features you either implement their features and options or you don't use their names.

> I'm ok with using ls and echo and names of other such basic commands as aliases, but with tools like wget and curl that are known for their vast array of useful features

Well, I can't do my typical ls -la either.

help( / man / Get-help) dir brings up the help menu for Get-ChildItem

Sure, go ahead, ruin my joke :)

More seriously, how many seconds did it took for the PS to answer to that command?

    Measure-Command {dir C:\}
    TotalMilliseconds : 2.9708

    Measure-Command {Get-ChildItem "C:\"}
    TotalMilliseconds : 2.4161

I feel like I should point out that `Measure-Command {dir C:\}` is just aliasing gci.

    PS> Measure-Command {Start-Process cmd -ArgumentList '/c dir c:\'}
    TotalMilliseconds : 14.0138

    PS> Measure-Command {gci C:\}
    TotalMilliseconds : 10.7484
Second run on each of those went down to closer to 40% of each, yay caching.

Of course, the start-process is possibly taking up a chunk of time, there. With no measure-command for cmd, it makes it a little harder to gauge.

Compare it with cmd.exe's dir

  c:\temp>timecmd dir c:\
  Volume in drive C is Windows
  Volume Serial Number is A0A8-6684

  Directory of c:\

  01/11/2016  12:45    <DIR>          AMD
  17/11/2016  12:52    <DIR>          Windows
                 9 File(s)         25,337 bytes
                18 Dir(s)  71,423,356,928 bytes free
  command took 0:0:0.08 (0.08s total)
bat from http://stackoverflow.com/a/6209392

I have had a quick look through here [1] and most of the answers involve timing precision of two significant digits. By that metric, PowerShell's 2.4ms clocks in at 0.00 seconds. Which means cmd.exe (at a precision of two significant digits) can't beat it.

[1] http://stackoverflow.com/questions/673523/how-to-measure-exe...

"2.4" or "0.0024" or "24000" all have two significant digits. Leading and trailing zeros don't count as significant digits.

My mistake, you are right [1]. Thanks for the correction.

[1] https://en.m.wikipedia.org/wiki/Significant_figures

and find that command prompt dir is faster because it's doing less, because it's less capable. It's not creating System.IO.FileInfo and DirectoryInfo objects for each thing in the directory.

Second time the HD has probably cached the result...

    Measure-Command { gci C:\ }
    TotalMilliseconds : 1.3334
It's pretty fast

At least Powershell has Unixy aliases for the common commands.

I don't know how many times I've been in a cmd shell and typed ls and then swore at things.

I just wrote batch files that serve as aliases for those. I type ls in my command shell and it does a dir /w behind the scenes, which makes it look more like how it looks in Linux anyway. Here are the ones I have:

* cat.bat: type %1

* clear.bat: cls

* diff.bat: fc /n /w %1 %2

* ls.bat: dir /w %1%

* pwd.bat: cd

* touch.bat: echo . >> %1

* top.bat: tasklist

All have an @echo off at the top too. Touch is a little janky, because I couldn't figure out how to actually create an empty file with nothing in it from the command prompt.

I'm actually not really a Linux person, but on Mac you kinda have to use these, so I got more used to using them than the Windows counterparts.

    copy nul %1 >nul
to get an empty file. It's not a replacement for touch, though, as touch will do something different to existing files. Your attempt will silently overwrite the file in that case.

Couldn't you just append null to a given filepath to get the same result, or am I misguidedly assuming that >> creates files that don't exist?

Interesting idea, but type nul >> file doesn't change the metadata, perhaps because nothing was written. But yes, it would at least not destroy files.

You could put the @ in front of the command like so:

1 line file: @type %1

Add posh-HumpCompletion https://github.com/stuartleeks/posh-HumpCompletion then you just need to type first Caps and hit tab

You can do the same thing with PSReadline, which is included in Win 10 installs.

No, dir `c:\ works` just fine.

It is a short version for

    Get-ChildItem -Directory C:/

first command works perfectly fine under powershell.

    ls c:\ 
or gci c:\

Nope - what makes you think that?

Being verbose would be a good thing (more readable than a cryptic acronym) if there was auto-complete support. A console should really be a small IDE that gives live feedback on what arguments are possible in the current context, etc. But that's not the way powershell was designed.

Actually, that's exactly how PowerShell was designed. Have you tried pressing <Tab>? Every command can be inspected and you get auto-completion support by default, for commands, parameters, even properties on returned objects (since the shell often knows what type is returned from a command).

There is auto-complete support. I just tested it (not a powershell user myself), and it seems pretty intelligent.

For example, if you type

    dir | sort <TAB>
it suggests Attributes, BaseName, CreationTime, .... All properties of file objects (which is what dir returns).

Also there is PowerShell ISE, which is a IDE for powershell, but I haven't really tried it yet.

That's not what I mean by autocomplete. What I mean is more like Visual Studio's intellisense, ie a drop down that lets you know what are all the options from there. You can type DIR <TAB>, that won't tell you that you can apply the parameters "/p" or "/w" nor what these parameters mean. ISE does a slightly better job but is based on a static specs, rather than the current state of the system. So it won't list the VM names currently active in the system for instance.

Yes you can type -?, but that's as bad as having to go on the web to read the documentation. It's disruptive. The point of a good auto-complete is to have a list at your fingertips with a short description of what it does, without interrupting your train of thought.

That's exactly how it works!

You can press ctrl+space and it pops out a list of options to choose from, then you move with the arrow keys. It works for parameters and values (if there's a set to choose from):

I've taken a screenshot to illustrate: http://i.imgur.com/d7MVYma.png

If you type: dir -<Ctrl+Space> PowerShell will list all available parameters below, and allow you to tab through them.

The tab completion is not static either. If you type: ps <Tab>, it will tab through all the current processes.

I you type "Start-VM -name <TAB>", it won't list the list of the VMs, but rather the list of the files in the current directory. That's not exactly what I would call insightful.

I didn't know about the CTR+SPACE. That being said it doesn't seem much more insightful than TAB. And no description of what the argument does.

The issue with "Start-VM -name <TAB>" is not an issue with Powershell itself, but with the Start-VM cmdlet; the Start-VM cmdlet could have been designed to complete from the list of VMs.

The ise can do that if you've got the object at the time you're writing like that, it can't run a command for you as your typing it.

You'll never get a drop down list in the host terminal windows has it doesn't have a GUI layer like that. Wrap it in a electron app and make one.

you can type `dir -<tab>` and cycle through the options. type `get-help dir` to see what they do or install posh-git and use `dir -<ctrl-space>` to get a menu of options to choose. I didn't know about -?

You'll never get a drop down list in the host terminal windows has it doesn't have a GUI layer like that.

Except you do, with PSReadline, built into Windows 10 PowerShell.

Sorry yes that's psreadline not posh-git like I commented. I wouldnt' call that a drop down though, that's just adding to the output isn't it? You know I've no idea how that works, could come in handy actually I should learn.

It's as close to a dropdown as you can get in the CLI without putting GUI elements over the top. Try

    gci -  then ctrl+space
The available parameters appear on the screen, you can select one with the arrow keys, and tab, when you choose one and press space, they all disappear again. It's interactive, dynamic, it changes depending on how much of the parameter name you've typed - it's not just printing to the screen and stuck there.

Have you even used Powershell? :)

> 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.

This is an older change - I have this behavior in 10.0.14393.0 (ie, current stable).

cmd launching posh is new though.

There's an option in the Taskbar settings: »Replace Command Prompt with Windows PowerShell in the menu when I right-click the start button or press Windows key+X«. I suspect the default value for that setting has been false, so far.

I have that here in stable. I suspect you're right and changing the default might be what they mean (I think I already changed it because cmd is gross).

I know we have machines with lots of RAM now, but at 90-100MB (PS) vs 4MB (CMD) [1] RAM usage per instance (not counting the conhost instance that also spawns), I think I would still want CMD around.

[1] Quick check done on my Win7x64 laptop.

Does that really affect you in any way? (And I'm really asking, not trying to be snarky, I've got 64gb on my main dev machine so I really don't know...)

I can't imagine any scenario in my actual usage where I'll have 4mb (plus whatever is needed to actually do the work) but not 100mb (plus whatever is needed to actually do the work).

Also, on my machine (windows 10 stable branch) each PS window takes up about 20mb (at least the task manager is telling me that, I didn't dive any deeper)

My work machine is not nearly that beefy. :| I do often have 8-10 cmd windows open. According to task manager on my machine, each PS instance on start is 90-100MB. I didn't dig deeper to see if that RAM usage would shrink over time.

I'm pretty sure the Softpedia article is incorrect in saying that "cmd" is now aliased to powershell. I installed the update, and running cmd from search bar (win cmd enter) and from run dialog (win+r cmd enter) both launch cmd.exe.

The release announcement post says "Typing “cmd” (or “powershell”) in File Explorer’s address bar will remain a quick way to launch the command shell at that location."

I honestly kind of wish it was aliases - I regularly launch a cmd window due to decades of muscle memory, then remember I really probably wanted powershell.

PS is pretty robust, but it's a bit verbose, to say the least.

As noted elsewhere, command processors internals like 'dir' and 'copy' are supported, but aliased to something else. In the case of dir it's aliased to Get-ChildItem, and copy to Copy-Item.

The latter breaks my favourite quick file create method:

C:\temp>copy con example.bat [return] commands go here^Z 1 file(s) copied.

I had a quick look at Copy-Item and there is no obvious way to use it to the same effect that I can see.

[edit: added the [return] to make it more obvious]

Hopefully one day Bash will be the default Windows CLI.

Bash has its warts too. Treating everything as strings can cause headaches when filenames have spaces. As a long-time Linux user who recently learned some powershell, I find Bash rather primitive after getting accustomed to an environment where everything is an object.

I wonder how feasible it would be to build a powershell-like environment for Linux on top of Python.

>I wonder how feasible it would be to build a powershell-like environment for Linux on top of Python.

Well, you could just run PS itself.


It's probably doable with time... and (mostly because nobody's directly linked to it yet) the official Powershell is now on github under the MIT license:


There is Xonsh [0].

[0] http://xon.sh/

That was the approach I took before inventing PowerShell. We didn't WANT to invent a shell - we were forced into it.

The problem was that Bash on Windows wasn't effective. At the heart of the matter is the difference in architecture between Unix and Windows. In Unix, most everything is a file so if you can modify files and restart processes, you can manage everything. In Windows, most everything is an API so tools that manipulate files don't do much for you.

Ergo - we needed an admin automation model which supported an API oriented architecture. Thus PowerShell.

NOTE - Bash on Windows today has a very different focus - it is not about managing Windows (which it still doesn't do) - it is about using OSS tools to develop OSS Software. It does a great job at that.

Jeffrey Snover [MSFT]

I don't see PowerShell as a Bash replacement, I see Bash as more of a cmd replacement. I'm a user, but I'm also a developer so Bash works for my needs. PowerShell, not so much. It's powerful, no doubt, but it's not the solution I was looking for. Admins can always fire up PowerShell if they need it.

I didn't WANT to run Windows - I was forced into it.

Path of the course perhaps. After 30+ years of fighting a what was always a "rear guard action" against the prevailing dominant Unix customs and methods Nadella has switched Microsoft and Windows into a full-on conformist mode by removing the immediate -> monetization of the OS and thus the need to be "different".

It would not surprise me in a few years to come, to find even sooner than expected that "Windows" had become another variant of Unix in effect if not entirely in fact.

Microsoft has made some good changes, but don't get your hopes up! :)

Maybe an year or two after all Linux users migrate their to some idiom of Python.

Or maybe a compatibility layer, where they integrate the most common bash commands and Unix utilities. I prefer Git Bash when on Windows for this reason.

There is a compatibility layer now, it just happens to be a complete Ubuntu environment.

More likely that PS will be the default Linux CLI than visa versa. Looking at their technical merits and all...

Having repl of some strange CLR language as primary shell is weird but having port of DOS shell is weird too.

if you put it this way, having a repl of an organically grown language that can barely do arithmetic is weird, too.

What happens if someone have batch files for some work flow routines?

Have to re-write all of them?

Nothing. Bat is a filetype, that file type is bound to executive in CMD's context. You can even execute it from PS and have it run the Bat perfectly normally (using CMD).

Ditto with VBS. You can execute VBS files from any context on Windows (e.g. double click, PS, CMD, etc) and they'll always use the cscript engine.

Weird. I have 14971 installed and when I type CMD in the "ask me anything" box or in the alt-r box I get good old CMD shell. Is this a config thing ?

They're not removing cmd the console host. If you shift-right-click a folder the context item is powershell now instead of command prompt.

The article would partially disagree with you:

> 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.

Imho that sounds like stupid idea (and I like PS).

Currently powershell just shells out to cmd.exe to run normal command line apps And handle text streams anyway. How would that work?

My guess is that MS will keep old cmd in place in system32, and do some tricks with search paths to divert "unqualified" cmd to PS.

Who does that?

Same, if I type "cmd" into the start menu, I get plain old cmd.

I'm probably wrong, but can you not type "ps" into CMD and get the PowerShell prompt? If so, can you do it the other way around as well?

It's actually 'powershell' and not just 'ps', but you are right. Typing 'powershell' gets you to PS and typing 'cmd' gets you the command prompt.

you can run "powershell" from a CMD prompt and "cmd" from a powershell prompt.

You can also nest prompts to switch context between them.

You can also `start /b cmd` for some very interesting results. I still have not understood why this works this way.

I like the signalling that perhaps Microsoft is taking the command line shells seriously for their users for the first time in a long time.

> Microsoft is expected to get rid of [Command Prompt] completely at some point in the future.

This is extremely unlikely to ever happen. As long as people have .cmd and .bat files they need to run, cmd.exe will still be around. They're not going to just remove it and break all those scripts.

That is right.

CMD.exe will be around to support script execution for a long long time.

Jeffrey Snover [MSFT]

Uh-Oh. Work has many cmd scripts in use. They'll all have to be tested under PS now.

No, batch files won't magically get run by PowerShell (and in fact cannot, except for very trivial stuff).

By the way, where does the capitalized kebab case come from? Prior art or just Microsofts general hankering for capitalization (e.g. C#s Class.DoSomething() vs Java's Class.doSomething())?

Wikipedia calls it Train-Case but doesn't provide a source. https://en.wikipedia.org/wiki/Letter_case#Special_case_style...

Note that it's not quite "kebab case". The dash only separates the initial verb from the object, but the rest of it is regular PascalCase. So Get-ChildItem, not Get-Child-Item.

PascalCase is well-established in the Microsoft developer ecosystem. It goes at least all the way back to Win16 and Windows 1.0 (it using the Pascal calling convention might have something to do with it, perhaps).

More importantly, it is used uniformly in .NET, and PowerShell builds on top of .NET, and deals with .NET objects directly, which have properties like e.g. `FullName`. So it makes sense for consistency.

What you're thinking of is PascalCase


Your parent probably meant Kebab as in the dash (skewer-stick) between words.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact