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 | web | 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)

  MODE CON COLS=200
  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]

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


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?

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.


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!


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.


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

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


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?


Someone else posted the evidence below.

In an attempt to understand and empathize with people who do not share my opinions, I looked back through some of your post history and you said this 5 days ago:

"It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. You didn't have to read anything or search around in order to change all of those settings in the GUI."

Maybe it's possible you're not familiar with people who use powershell because you tend to stick to the GUI?


That's a good point - almost everywhere I go as a consultant...their IT people use the GUI to manage things and not PowerShell.

Most places that I've seen automate things with a .NET program whether it's a service, a console app run via Task Scheduler, an SSIS package and in a few cases - a desktop app.

EDIT: I'm a programmer and not a sysadmin except for on my own network where I do prefer "the easy way" as opposed to the way where you have to do rote memorization to perform simple tasks. If I automate anything, it's also done with .NET or Node.js because I like the tools better and my stuff runs everywhere without performing any ceremonies. I do visit a lot of client sites though and I work with client sysadmins regularly. I'm on the East coast and I work in the NY/NJ/PA area. Also the reason I like bash better is because if I have to memorize anything (and I do, for Linux work)...I'd rather have it be something terse.


You seem to be missing the fact that powershell is just designed better. Take powershell vs bash. Bash operates primarily on strings. In powershell everything that is interacted with is an object. This wont really effect you in day to day interactions, but it is incredibly useful when you decide that you want to automate something. This combined with the fact that powershell is built on the .net framework means that there is a simple way to extend it from C#. You should give it an honest try sometime. Its not really that much more verbose in everyday practice and it has lots of tools around it that make life simpler.


https://www.powershellgallery.com/stats - 100k+ downloads of DSC resources in the last 6 weeks.

https://github.com/search?l=PowerShell&q=powershell&type=Rep... - 7,600 GitHub repositories (compared to 20,000 'shell' and 19,000 'perl')

40k questions on StackOverflow tagged PowerShell, vs. 54k tagged 'Perl', 50k tagged 'shell', 76k tagged 'bash'.

20k /r/powershell subscribers, 10k /r/bash subscribers on Reddit.


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

Absolutely because of twenty years of muscle memory.

But once Powershell is the default and they learn about the wonderful "gip" alias, they'll be hooked. "gip" in case people don't know is an alias for Get-NetIpConfiguration which is a more powerful version of IPConfig.

PS - "gip -all" is useful. "gip -all -d" for more detailed results.


Why would I run PowerShell for ipconfig? Just do the easiest thing.

Running a multi line script that does nearly anything important? Well yes I am definitely going to use PowerShell.


For simple tasks such as running a command, sure. But if that admin needs to do anything more complex, such as parsing the output of ipconfig, they're most likely going to use powershell.


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


I compared Powershell to Python regarding projects, not Bash.

It could have been 1. a shell 2. an automation tool 3. a scripting language, yet it fails at 1., is ignored regarding 3., and only succeds at 2.


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]


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]


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


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.

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


Registration is open for Startup School 2019. Classes start July 22nd.

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

Search: