terminal.integrated.shell does not support parameters

[be5invis]

set

"terminal.integrated.shell.windows": "C:\\\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -ExecutionPolicy RemoteSigned"

does not work. If I remove the parameters Powershell refuses to run script, even $PROFILE.

[coreh]

Also hit this on OS X.

Was able to work around it by creating a shell script that then invokes the shell with the desired parameters.

Try creating a .bat file (or the power shell equivalent of that) with your command line.

Would be nice if we had "terminal.integrated.shell.osx.args": [ "--foo", "bar" ] or something.

[Tyriar]

@coreh nice workaround :)

[jbruettcva]

what i don't understand is where is VS Code pulling the execution policy from? if i run powershell.exe -noprofile or ise -noprofile they both show get-executionpolicy as remotesigned. But with powershell set as the default integrated shell based on @be5invis settings (without the executionpolicy switch) it shows as restricted.

[The-New-Guy]

@jbruettcva I'm just taking a guess here but I think the issue is VSCode is somehow opening a PowerShell instance with all execution policy scopes set to "Undefined". If you run the following command within the integrated shell you will see all scopes set to this:

Get-ExecutionPolicy -Scope CurrentUser
Get-ExecutionPolicy -Scope LocalMachine
Get-ExecutionPolicy -Scope Process

# These below are for GPO enforced execution policies
Get-ExecutionPolicy -Scope UserPolicy
Get-ExecutionPolicy -Scope MachinePolicy

I could be wrong but I am guessing that when all 5 scopes are set to "Undefined" then Windows will by default use a "Restricted" policy to play it safe. If you set any one of those scopes to something other than "Undefined" you will see Get-ExecutionPolicy now displaying the same value:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Aside from the "Process" scope, all execution policies are stored in the registry. So I can only imagine there might be an issue trying to access those registry keys at the time PowerShell is being launch from VSCode. Generally, when most people setup their execution policy initially, they don't specify a scope, which means by default they are setting the "LocalMachine" scope, which should be readable by all.

Set-ExecutionPolicy

EDIT

Looking into this further I found that the instance of PowerShell that is getting loaded in the integrated shell is in fact an x86 version of PowerShell. Which is odd since the path to the PowerShell executable we are providing is for the x64 version. My guess is Windows sees that VSCode is an x86 app and automatically runs the x86 PowerShell version. If you run the following you can see for yourself:

$env:PROCESSOR_ARCHITECTURE

Further more if you go to the following location, run the x86 instance of PowerShell and then run the 5 Get commands I listed above you will see the same settings you see inside the integrated shell. So this looks more to be an issue with loading the wrong architecture of PowerShell.

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

This of course means that you can go into the x86 version of PowerShell, set your execution policy as you like and then that setting will be present when loading the integrated shell.

[Tyriar]

@The-New-Guy yes just using "poweshell.exe" will use the 32 bit version. If you have any ideas how to communicate/guide users to use the 64 bit version join in at #7095

[chintan9]

#7341 bat file is working now @Tyriar thanks

https://github.com/chintan3/vscodetest/blob/master/README.md

[Tyriar]

Just added the config keys terminal.integrated.shellArgs.<platform>, tested by making sure .bash_profile ran with this config:

{
  "terminal.integrated.shell.linux": "bash",
  "terminal.integrated.shellArgs.linux": [ "-l" ]
}

[erichiller]

The terminal.integrated.shellArgs.windows parameter was never added I take it? Just OSX and Linux?

{
    // The path of the shell that the terminal uses on Windows.
    "terminal.integrated.shell.windows": "C:\\Windows\\system32\\cmd.exe",
    "terminal.integrated.shellArgs.windows": [
        "/k echo foo"
    ]
}

[Tyriar]

@erichiller yes, it was added and then removed when we tested and realized it didn't work. This is due to an upstream issue. It's being tracked in #8429

[buckett]

@Tyriar I think the upstream issue (#8429) is now fixed so might Windows get shellArgs now?

[Tyriar]

@buckett yep, Windows shellArgs support is coming in v1.7 (in Insiders now)

[erichiller]

With 1.7.1 out, I haven't been able to get this working. Was it possibly delayed?

[Tyriar]

@erichiller it should work fine, are you getting some error message?

[delence]

Works for me with version 1.7.2! I'm using powershell and able to set execution policy and add the node_modules/.bin to the path.

"terminal.integrated.shell.windows": "C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe",
"terminal.integrated.shellArgs.windows": ["-ExecutionPolicy", "RemoteSigned", "-NoExit", "$env:path+=";$pwd/node_modules/.bin""]

[AdsonCicilioti]

@delence ... U can help me?

I Need set this args:
PowerShell -ExecutionPolicy Bypass -NoLogo -NoProfile -NoExit -Command "Invoke-Expression '. ''%ConEmuDir%\..\profile.ps1'''"

How to set Correctly?

[AdsonCicilioti]

I got it!
I will insert the Cmder profile and tool on Vs Code terminal!
Thx guys!

"terminal.integrated.shellArgs.windows": [
        "-ExecutionPolicy",
        "Bypass",
        "-NoLogo",
        "-NoProfile",
        "-NoExit",
        "-Command",
        "\"Invoke-Expression'.''Z:\\Apps\\cmder\\vendor\\conemu-maximus5\\..\\profile.ps1'''\"",
        "-and",
        "\"cls\""
    ]

[Boggin]

With VS Code 1.15.1 x64 on Windows 7 and PowerShell 5.1

    "terminal.integrated.shell.windows": "C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\powershell.exe",
    "terminal.integrated.shellArgs.windows": [
        "-ExecutionPolicy",
        "Bypass",
        "-NoLogo",
        "-NoProfile",
        "-NoExit",
        "-Command",
        "\"Invoke-Expression '. ''C:\\tools\\cmdermini\\vendor\\conemu-maximus5\\..\\profile.ps1'''\""
    ],

This doesn't load my themed prompt. It prints out the Invoke-Expression line instead of running it.

Invoke-Expression '. ''C:\tools\cmdermini\vendor\conemu-maximus5\..\profile.ps1'''
PS C:\source\>

I changed the -Command to the following and it worked for me (although I've yet to chain the cls).

". 'C:\\tools\\cmdermini\\vendor\\conemu-maximus5\\..\\profile.ps1'"

[kim0]

@Tyriar .. Would you please explain what does running "bash -l" buy us on osx (why run .bash_profile?)

[coreh]

@kim0 You can add useful customizations to your shell via .bash_profile:

• Adding aliases to avoid typing out long commands (e.g. gst => git status)
• Setting your prompt (PS1) to display which branch you're on
• Setting the default editor
• Enabling colored output for some commands

Edit: @kim0's question was about running.bash_profile vs .bashrc, so my answer doesn't really make sense

[kim0]

@Tyriar @coreh .. Thanks, I would like to argue that always launching a bash login shell is incorrect. Bash offers two initialization schemes

• .bash_profile .. Which is read only once upon login (ssh or console). This is supposed to do initialization that should only be done once (setup env vars, snapshot your home directory, send an email that I'm starting my day ...)
• .bashrc .. This runs everytime a new bash runs (like opening a new terminal window)

I would argue that we should not be launching bash -l, instead we should only be launching bash and any needed customization should be put in .bashrc (or .bash_profile really if it's a one time thing!). Using bash like it was meant to. You can check more info with this superuser answer https://superuser.com/questions/183870/difference-between-bashrc-and-bash-profile

Ofcourse I'm happy to be wrong about all of this, corrections welcome. But just launching bash -l everywhere did not sound right to me.

Thanks!

[Tyriar]

@kim0 you're preaching to the choir, if you dig through issues you will see me arguing exactly this and I think quoting that exact link.

However, macOS is different in that ~/.bash_profile is not run when you login, so running a shell as a non-login shell results in an environment that hasn't run ~/.bash_profile. All terminals on macOS run as a login shell by default, so leaving this out caused many users headaches which made me back down on my purist stance 😉

[coreh]

@kim0 Oh, sorry, I understood your question as being about the general purpose of .bash_profile. I was not aware of the distinction between .bash_profile and .bashrc, so today I learned something new. 😄