Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build | Hacker News Reader

Microsoft Replaces Command Prompt with PowerShell in Latest Windows 10 Build

news.softpedia.com

392 pointsctoth342 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)

  MODE CON COLS=200
  Clear-Host (I get some artifacts)

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

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

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?

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.

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.

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]

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

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!

https://technet.microsoft.com/en-us/library/dn167709.aspx

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

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

https://brianreiter.org/2010/01/29/powershells-object-pipeli...

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

    or

    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:

http://www.gossamer-threads.com/lists/linux/kernel/2218440

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:

https://news.ycombinator.com/item?id=12319670

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

https://github.com/PowerShell/PowerShell-RFC/blob/master/X-R...

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.

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!

Courage!

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.

ls=dir=gci="Get-ChildItem"

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?

Thanks.

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.

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

source:

http://winaero.com/blog/microsoft-is-killing-the-classic-pai...

http://winaero.com/blog/microsoft-releases-new-get-office-hu...

http://winaero.com/blog/edge-gets-epub-support-in-windows-10...

https://www.neowin.net/news/cortana-will-now-keep-track-of-y...

https://www.neowin.net/news/microsoft-adds-support-for-surfa...

https://www.neowin.net/news/windows-10-build-14971-for-pcs-n...

https://www.neowin.net/news/here039s-what039s-fixed-improved...

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

http://imgur.com/kDQVBZw

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

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.

I just install Gow.

https://github.com/bmatzelle/gow

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

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.

Official announcement: https://blogs.windows.com/windowsexperience/2016/11/17/annou...

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.

https://github.com/PowerShell/PowerShell/blob/master/docs/in...

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:

https://github.com/PowerShell/PowerShell

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

https://en.m.wikipedia.org/wiki/PascalCase

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

Personally I want to use PowerShell. The show-stopper for me is that I cannot set default encoding for output redirection (>) to ascii/utf-8.

This is so important for things like Google Code Jam, etc.

I agree it's annoying¹, but I wouldn't call it a show-stopper. I have resorted to Out-File -Encoding <foo> wherever I need file output.

_________________

¹ The redirection syntax cannot easily accommodate an encoding, so in general you cannot really use it everywhere anyway. I often need to use the system's legacy codepage instead of Unicode, so UTF-8 by default would be just as useless there. GCJ, however, could just accept text in any common encoding instead of insisting on ASCII. Detecting UTF-16 isn't hard, even though common Unix tools tend to treat it as arbitrary binary data instead of text.

Generally I'd say > is a convenience feature more than an actually useful construct, at least in a shell like PowerShell. On Unix-likes > simply dumps bytes since that's what the shell is built around. For PowerShell you could just as well say you'd dump CLIXML instead, since the shell works with objects. Since you have a few valid options you could either try to shoehorn them into the syntax, either with various funny characters

    Get-Data > data-as-utf8.txt
    Get-Data >@ data-as-clixml.xml
    Get-Data >% data-as-utf16.txt
    ...

or add another expression somewhere

    Get-Data > data-as-utf8.txt,[Text.Encoding]::Utf8

all of which are options I'd say don't really fit into PowerShell, nor should they be entertained. Does it really matter whether the last part of a pipeline is a redirection operator or just a terminating command that writes the data to a file? Conceptually I'd say having the pipeline end in a pipeline element instead of something entirely else is preferable since it reduces the number of distinct concepts.

Here is how you do that:

$PSDefaultParameterValues["Out-File:Encoding"]="utf8"

Jeffrey Snover [MSFT]

How does PS compare to installing cygwyn and using bash ? (from a Linux user perspective) does it support grep, find, ls, PS, pipes, etc?

Windows 10 actually has some fancy linux emulation stuff ( https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the... ). Personally I wanted to like PowerShell but its syntax and semantics were infuriatingly confusing.

better?

with PS you pipe objects. The pipeline is very much the way to move data between cmdlets.

each of the linux commands you listed has an equivalent PS cmdlet.

It would be nice, if they would improve the terminal window a bit with tabs and the like (like Gnome Terminal for example).

It's already slightly better in Win10 (in case you have not tried it yet).

Meanwhile, Gnome Terminal has been taking away the tabs...

Yeah, I haven't liked many of the changes in Gnome over the past few years. Terminator as a terminal emulator has been rock solid though. Highly recommend it.

Did they, why?

I have switch to xfce4-terminal for a while in all my system....

They didn't take away terminal tabs.

Psst, try pressing ctrl+alt+t in a terminal window

So many surprise and complains... Simply change what you want, PowerShell is cross-platform and opensource: https://github.com/PowerShell/PowerShell

Did they finally add persistent history oit of the box?

Peristent = close the terminal then open it and the last commands are available.

And yes, I know you can hack it to be persistent.

I use ConEmu with PyCmd but I surely see why Powershell is an interesting alternative. I'm just too lazy to get used to its command syntax.

I think this is probably a step in the right direction, but it still only has 16 colors. When are we going to get a command prompt with at least 256 colors on Windows? There are already a bunch of linux consoles out there with true color, but nothing for Windows. Am I crazy for caring about this?

I welcome this 100%.

I hope the old CMD.exe is still available somewhere.

Is it Unicode by default now?

Will Far Manager still work?

Windows fan here. I hate PowerShell and I'd much rather have Bash built into Windows. Things I hate about PowerShell:

- You can't even run your own scripts without performing the Set-ExecutionPolicy ceremony first or signing your scripts.

- It's way too verbose.

- It's a strange bird that next to nobody uses, so there's zero motivation to learn it.

- It's not "old reliable". You can't depend on it working due to the first point and also due to the fact that they're still working on it and even in 2016 they broke some PowerShell stuff with updates that needed to be uninstalled (KB3176934).

Literally every windows admin uses it. It's the official commandline interface for microsoft software.

Every piece of microsoft software must provide a ps interface. It's an engineering directive.

It is strange to claim no one really uses powershell. It is widely used in the Windows world.

The main complaint I see about powershell is that it isn't bash. The object pipeline in powershell can be so much more powerful than parsing text between commands. After all, that's why we have data types instead of storing everything in strings.

It's not widely used in the Windows world from what I can see.

Walk into any office and ask an IT guy to run "ipconfig". They'll open up cmd.exe without even thinking about it.

I read a lot of programming tutorials. Nobody ever reference PowerShell in them. They always instruct people to open cmd.

Do you have any evidence to the contrary?

Every windows admin uses it but all the admins I know don't particularly like it or fully understand it. They do like what they can do with it, that they can script almost everything, and it's far better than cmd.exe but honestly the syntax and semantics are pretty baffling.

There's a lot of cargo-cult copy and pasting in the powershell community.

That's all correct and it is the right way to do things (especially from Microsoft's perspective). However, the main goal of Powershell seems to be providing a scripting language that can automate Windows internals and not a shell in which you live in. Powershell is just a nice REPL, not so much a shell as you might be used from Bash.

We have had Powershell for 10 years now. Has it taken off in a big way? No. The admins you mentioned use it because simple automation is the one thing GUIs cannot provide and MS had to face this after over a decade of denial.

Do people get out Powershell instead of Python to do cool new projects that are unrelated to devops or admin work? Some maybe. But the real music plays somewhere else. And some of the reasons for that have been mentioned by the GP.

I wouldn't take out bash or zsh or whatever else to do a project either. But I do use it when I want to run a bunch of cmdline tools.

Right tool for the job and all...

Powershell is designed for devops and admin work. I wouldn't use it for anything else.

> Literally every windows admin uses it.

And how much people with those be? Probably a lot less that software developers in general, and non-windows admins.

"admin"

This would be a good move if it was on Windows Server.

I've never quite understood the concern about needing to Set-ExecutionPolicy before running scripts.

In Unix, you have to chmod a+x a file before running it. And you have to do it for every script you want to run.

So to run 1 cmdlet to enable all scripts seems a bargain. (Honestly I could be missing something and I probably am because you are not the first person to mention it. I just can't connect the dots.)

Jeffrey Snover [MSFT]

My problem with the Execution Policy is that it's useless in practice since it doesn't actually prevent anything (so it annoys me every time). What was the motivation for adding it since it's not a real security feature? If it actually prevented executing stuff full stop it would be cool. The signed script concept is cool... I wish I could do that with Python.

Was it just to prevent accidental script execution?

That is correct (prevent accidental script execution).

It is ABSOLUTELY NOT a security mechanism. That is why we we support this:

Set-ExecutionPolicy -ExecutionPolicy Bypass

I wanted to make it:

Set-ExecutionPolicy -ExecutionPolicy DoAnythingBecauseTExecutionPolicyIsNOTASecurityFeature

But the team didn't like that. (I should have overruled them on that one :-) ).

Jeffrey Snover [MSFT]

I think the problem is that when you chmod a file it stays chmoded. With the Set-ExecutionPolicy I find that I have to do it every time I start a shell. I also run a lot of headless scripts (AWS cloud-init, services, etc.) and it's always a pain resetting everything every time. With Unix, I know that a script is executable or not, with PS I don't.

Also, I might not want every script to be executable. With Unix I can choose which ones are executable and by whom. With PS it's all or nothing. :/

Yikes! - you shouldn't have to do Set-ExecutionPolicy every time you start a shell. Something is definitely wrong there.

Try doing a: Get-ExecutionPolicy -List to see what is setting it.

Then use -SCOPE on Set-ExecutionPolicy.

BTW - I hear you on the "only chmod the scripts you want" - that is a nice benefit of the Unix model.

Jeffrey Snover [MSFT]

I totally get where you are coming from. When having to do work on Windows, I used to go out of my way to avoid PowerShell.

I finally gave it a solid chance one day and I've found that it can be surprisingly nice and powerful to work with.

You can globally disable policy enforcement. Maybe not the most "secure", but it's not something I wish to bother with. There is also a really nice package management system for PowerShell modules with things like git integration and etc.

You can check out my shell configuration here: https://gitlab.com/lholden/WindowsPowerShell

Java developer here, multi-OS fan. I'm using both PowerShell and bash from Windows Ubuntu subsystem. I prefer PS on Windows because I do like its object pipeline, but have to use bash for some cross-platform automation.

Powershell users don't age gracefully, that's for sure. You'll learn some arcane long-winded way of doing something in v3 and it will be relaced with something far better. Unfortunately, you'll still have to know the old way.

As for longwinded, I hate using ACL in Powershell. Let's say you have to reestablish FullControl on a bunch of files as an Administrator and you don't have Write access. It's so convoluted and it can even fail silently. So much easier to just use icacls in a single line.

I'm going to address each bullet:

- Set-ExecutionPolicy can be set with a single click from the "For Developer Settings." Just scroll down and hit Apply three times and your machine has sane developer defaults (inc. ExecutionPolicy).

- The verbosity means that you can "guess" PS commands. Each PS command is a set layout with an action word (e.g. Add, Clear, Get, Write, etc) and then target (e.g. Set-Alias, Set-Date, Set-Service, etc).

- A ton of people use PS. In particular SysAdmins are moving from VBS/Bat to PS in droves. No clue what communities you hang out with where nobody uses it?

- It is definitely still a work in progress. But most of the core parts of the language hasn't changed much, if you wrote a PS file three years ago it likely still works today. All they've done is add new cmdlets, new libraries, and new functionality which doesn't hurt backwards compatibility.

> If you wrote a PS file three years ago it likely still works today.

That's a really low bar.

Isn't Windows supposed to have a legendary commitment to backwards compatibility? 3 years of backwards compatibility would be nice for a bleeding-edge development environment like node.js that you can tear down and replace whenever you want, but not for your operating system shell.

Guess? With naming conventions like "Get-ChildItem"?

Major functionality, probably the worst name you could come up with.

A single anecdote doesn't discount a trend.

Being able to predict a PS cmdlet based on patterns works. I know, because I use it daily.

> as it replaces the super-popular Command Prompt

heh.

heh heh heh.

hahahahahahahahahahahahahahaha

Just another reason to stay away from Windows as a platform. Windows 10 is a moving target if you are trying to work with it.

Your .bat files still work, and you can use the legacy terminal if you I insist. All they did was change the default terminal from the archaic one to newer one they first introduced as a the non-default option only a mere decade ago.

There is no reason to be dramatic.

How is that any different from Linux distributions camping their default shell? Like back when debian changed their default shell to dash I don't remember anyone saying you should stay away from debian, even though it broke a lot of existing scripts.

That's a bit different. The change only exposed that some scripts were already broken and worked by accident. Specifying that your script should be run with #!/bin/sh and then using bash syntax is what broke them. It's a bit like naming your files something.c, writing the code in C++ and compiling with `cc` just because `cc` happened to be linked to `c++` on your system. It will work for you, but don't be surprised when you distribute the source and people have problems using it.

Scripts that used #!/bin/bash still worked, scripts that actually used only sh syntax and #!/bin/sh still worked.

So there is actually no difference at all on Windows, then. Batch files have .cmd or .bat extensions and will continue to be run by cmd.

Did you have a choice to upgrade? Could you reinstall the old version of you wanted? Windows has stripped that power from users.

What power was stripped? Cmd.exe is still there.

Debian didn't make a major change within a release.

If you're not a fan of change, I feel like software development probably isn't the right career choice.

I am a fan of change. Likely similar to the parent of your comment, I am a fan of change when I can control when those changes happen.

With Windows 10 I am sadly realising that I have very little control over when things change and even less knowledge of what those changes will be. For software, this is a nightmare. As a maintainer, I will never know what changes are going to affect my software if I am not informed.

As a user, I no longer know when a feature of my computer that I use daily will disappear. If I used cmd yesterday, will it disappear tomorrow?

Who wants to be the passenger let alone the driver of a car if it steers and accelerates randomly despite your best efforts to steer it and drive it? Would you get in a car that removed the gearstick without warning? Would you really want to be in a car that accelerated and steered at whim?

This is what Windows 10 feels like, particularly compared to my 20 years of using Windows prior to it (Win3.11, 95, 98, Me for a day, XP, Vista for as little as possible, 7 for a lengthy time). With each of those releases, updates were applied by me in a timely manner, with the crucial point being that I could apply updates when I found it applicable for my own personal machine. I could read up on the release notes for each update and service pack to see what was changed.

With Windows 10, I get updates applied in a phantom fashion and do not know what they contain. It's like Apple's vague "fixed an issue" release notes.

EDIT: I must state that the removal of features is not unique to Microsoft, given that sweeping changes affected my Mac after every release since Snow Leopard. However, the key difference is that with Windows 10 you will never have control over when things are installed (unless you use some of the finer controls for updates available with GPOs in an enterprise; still what's the point of having an AD when you don't have full control over the endpoint systems?)

In technology, there's points where certain things stabilize and change infrequently. You can only build great things when your foundation isn't changing all the time.

I'm not really a heavy shell programmer. I mostly use it for git and simple scripts.

IMO, nothing's really "sold" me on powershell. It's always come across as some tool that some people like, but I've never really seen a reason to use it. (As I don't do a lot of complicated things in the shell.)

Hopefully this is something that's easy to get used to.

Not sure how that is related. Its years ago i last time used Windows for anything development related. And honestly i would prefer the old cmd because its easy to install Gow into it. It seemed quite harder to have my common environment working properly in Powershell without actually learning at least some of that syntax stuff last time i tried.

I'm not a fan of BAD change.

Nothing would change if the pre-requisite to any given change was that everyone agreed on the change beforehand.

PowerShell is 10 years old.

You say that; and yet [32-bit] Windows 10 can still run 16-bit GUI applications originally compiled for Windows 1.0 back in 1985, more than 30 years ago. We aren't even talking about a recompile here, but straight up binary compatibility.

How many other OS/DE combos do you know that can boast anything similar?

PowerShell is fully backwards compatible with cmd. Try again.

No, it's not. PowerShell has aliases like 'dir' and so forth, but it's definitely not compatible.

This will break a bunch of legacy stuff. That stuff probably deserves to be broken; the cmd.exe syntax has always been pretty disgusting.

It's not compatible at the syntax level, but it will also not break anything either. Batch files written for CMD will still be executed by CMD, not PowerShell. Unless you have an application that prompts the user to open a command prompt and then send keystrokes there to run commands, nothing will be broken here.

Yeah, to hell with legacy stuff. Legacy stuff is why we can't have nice things.

Are they, though? None of the dir switches work in PowerShell..

No, it is mostly backward compatible. Not the same thing at all.

Powershell is very insecure and is heavily abused by potential attackers as it's more flexible than CMD.exe. Of course, arguing about CMD.exe vs PS.exe is pointless, but it still needs to be argued.

There has been a recent spate of talks in Blackhat conf. and other confs, about the versatility of PS.exe, how it is used to perform persistence in comparably little characters, or lines of script than CMD.exe

Some of my Win10 deployments even contain a script which silently disables PS.exe in the installation, and removes every reference to that executable in the registry. There are a few cases where I caught PS.exe re-spawning itself when a Win10 update arrives, so a PS-free deployment is hard to enforce.

I'm really confused here. What attack vectors apply to PowerShell, but not to a situation where I can invoke cmd.exe? I can tell PowerShell to only run signed scripts, and specify what signatures to honor, which is more than I can do with either cmd.exe or WSH. You're citing compactness of scripts, but a straight-up binary would be more compact still. I think I'm missing something pretty basic here.

> I think I'm missing something pretty basic here

I'm referring to something like Powersploit https://github.com/PowerShellMafia/PowerSploit/

Which is a post exploitation tool. Assuming you have a payload in Windows ready to execute, one typically wants to leverage tools already in Windows itself, like Powershell, which can make rootkits and other payloads have a lot less footprint, and make them difficult to spot using heuristics. Most crap payloads are actually easy to spot because their payload is massive.

Essentially my point is that you don't want to make it easy for attackers. For context, one would not want Powershell installed on 1000 Windows 10 installations.

I happen to get paid good money for deploying Win10 kiosks in different offices in my area and Powershell is one of many tools I routinely remove from Windows to decrease the attack surface in Win

Anything VBS can do, Powershell can do ("everything" that a running user has the security for). Number of characters isn't relevant to scenarios where you're running PS/VBS/CMD on a local machine.

PS - Your "PS breaker" machine configuration is going to cause problems. Several of Microsoft's installers already run PS scripts behind the scenes. Plus you're doing it for absolutely no technical reason (just ignorant fear).

Strange. Because its bloody hard to get powershell to run anything with default security settings.

Reply on news.ycombinator.com