Windows PowerShell should be the default terminal program on Windows

[daviwil]

I'd like to recommend making PowerShell the default terminal program on Windows when the user hasn't configured their path (and when the COMSPEC environment variable hasn't been explicitly set). Since PowerShell will now be the default terminal program in Windows 10 going forward (see blog post), I think it makes sense to make it the default in VS Code on Windows as well.

What do you think?

[dburt667]

I absolutely agree with PowerShell being Default Term.

[rkeithhill]

Agreed!!

[ChrisWarwick]

Yep. Please.

[laurekamalandua]

Couldn't agree more with the other people.

[mattmcnabb]

Can't argue at all. Seems natural that it would follow the Windows default command line program.

[johlju]

I agree

[Tyriar]

@daviwil isn't COMSPEC set by default? Is it possible to tell if it's explicitly set?

[tostca]

Sounds like an great idea :)

[MathieuBuisson]

I do agree.

[daviwil]

@Tyriar looks like it is set to cmd.exe by default. That was my understanding too but someone suggested that there are cases when it isn't set; I don't have any data to back that up. Even though Windows 10 is going to default to PowerShell in the UI now, I haven't heard whether they'll change COMSPEC to point to PowerShell. Either way, since PowerShell is far better than cmd.exe for developers, it makes sense to default to it in VS Code on Windows.

If the team decides it's better to stick with COMSPEC, I might see if users of the PowerShell extension would be OK with us auto-configuring the terminal to point to PowerShell on Windows.

[Tyriar]

I'm concerned about breaking people's workflow. The little experience I do have suggests that we may be by switching this. Specifically I recall it being very slow doing trivial commands and one of my most used commands before I jumped over to Linux wasdir/w which throws a scary looking error in PS.

By default on Windows does the post mean that powershell will appear first when you search for "cmd", with cmd.exe also matching the search? Because that at least gives people a very clear option, configuring the integrated terminal is a little less trivial. It also seems preferable to rather get the Windows team to make COMSPEC point to (64-bit) Powershell rather than updating every tool to work around it? Right now I believe it points at the 32-bit version of cmd.exe by default, even on 64-bit machines.

Having powershell update the config in the meantime makes total sense though (via a messagebox?).

[rkeithhill]

What this means (from the MS post):

In an effort to bring the best command line experiences to the forefront for all power users, PowerShell is now the defacto command shell from File Explorer. It replaces Command Prompt (aka, “cmd.exe”) in the WIN + X menu, in File Explorer’s File menu, and in the context menu that appears when you shift-right-click the whitespace in File Explorer.

Regarding:

does the post mean that powershell will appear first when you search for "cmd", with cmd.exe also matching the search?

No. Folks should always be able to find cmd.exe and run it if they need/want to.

dir/w which throws a scary looking error in PS.

Yes. There are cmd.exe built-in commands that are not completely emulated in PowerShell e.g. dir (alias) works but not dir/w. Folks have been learning PowerShell over the past decade and I think its time has come. The equivalent of dir/w in PS is dir | format-wide or dir | fw if you prefer to type less.

Also, try to do this with your CMD prompt. :-)

[stefanstranger]

I agree too.

[devlead]

Agree 👍

[apetitjean]

Of course!!!!

[zackJKnight]

I vote yes.

[happysysadm]

YES!

[Tyriar]

I haven't heard anything against this yet either here or from the team so I'd love to accept a PR from someone who knows things about powershell and see how it goes in Insiders 😛. Here are some recommendations on the implementation:

• Don't point at powershell.exe in PATH as this points to the 32-bit version on 64-bit machines
• Powershell should only be the default on Windows 10, use platform.isWindows, os.release() and process.arch to get whether it's 32/64-bit Windows 10 and point at correct path
• Move TERMINAL_DEFAULT_SHELL_WINDOWS in /src/vs/workbench/parts/terminal/common/terminal.ts to /src/vs/workbench/parts/terminal/electron-browser/terminal.ts and generate the path there (for architectural reasons).
• Point at the current Windows installation directory without any IO (env var?)

[rkeithhill]

@Tyriar The file .../electron-browser/terminal.ts doesn't exist AFAICT. Is the idea to create a terminal.ts in the electron-browser dir?

[Tyriar]

@rkeithhill yes this would need to be created, the reason being because you can't access require('os') or process from common/ as it needs to be able to run in a browser.

[jchadwick]

@Tyriar take a look at the above commit, which implements your requirements above (I think). All except the requirement to look at x86 vs. x64 - that is not necessary, as the path is same for both.

However, taking your direction literally, it does not call processes.getWindowsShell() in the case of Win10/Powershell and therefor does not take into consideration process.env['comspec'] to allow the user to override.

Is this what you intended? Or, should processes.getWindowsShell() be updated to return Powershell instead? I realize this could have unintended effects, since getWindowsShell() seems to be called in multiple places by VSCode internally...

[Tyriar]

Thanks @jchadwick, let's discuss in the PR.

[Tyriar]

To verifier: check that powershell is now the default terminal shell on Windows 10

[ishitatsuyuki]

Please update the documents: https://code.visualstudio.com/docs/editor/integrated-terminal

[Tyriar]

Thanks @ishitatsuyuki, created microsoft/vscode-docs#891