New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

terminal.integrated.shell does not support parameters #7266

Closed
be5invis opened this Issue Jun 6, 2016 · 22 comments

Comments

Projects
None yet
@be5invis
Copy link
Member

be5invis commented Jun 6, 2016

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

This comment has been minimized.

Copy link

coreh commented Jun 6, 2016

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

This comment has been minimized.

Copy link
Member

Tyriar commented Jun 7, 2016

@coreh nice workaround :)

@jbruettcva

This comment has been minimized.

Copy link

jbruettcva commented Jun 7, 2016

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

This comment has been minimized.

Copy link

The-New-Guy commented Jun 7, 2016

@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

This comment has been minimized.

Copy link
Member

Tyriar commented Jun 7, 2016

@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

This comment has been minimized.

Copy link

chintan9 commented Jun 7, 2016

@Tyriar Tyriar closed this in 31bcb5a Jun 8, 2016

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Jun 8, 2016

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

This comment has been minimized.

Copy link

erichiller commented Jul 11, 2016

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

This comment has been minimized.

Copy link
Member

Tyriar commented Jul 11, 2016

@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

This comment has been minimized.

Copy link

buckett commented Oct 26, 2016

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

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Oct 26, 2016

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

@erichiller

This comment has been minimized.

Copy link

erichiller commented Nov 20, 2016

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

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Nov 20, 2016

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

@delence

This comment has been minimized.

Copy link

delence commented Dec 2, 2016

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

This comment has been minimized.

Copy link

AdsonCicilioti commented May 7, 2017

@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

This comment has been minimized.

Copy link

AdsonCicilioti commented May 7, 2017

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

This comment has been minimized.

Copy link

Boggin commented Aug 22, 2017

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

This comment has been minimized.

Copy link

kim0 commented Sep 10, 2017

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

@coreh

This comment has been minimized.

Copy link

coreh commented Sep 11, 2017

@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

This comment has been minimized.

Copy link

kim0 commented Sep 11, 2017

@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

This comment has been minimized.

Copy link
Member

Tyriar commented Sep 11, 2017

@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

This comment has been minimized.

Copy link

coreh commented Sep 11, 2017

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

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.