Code mangles PATH variable that it's opened with

[alexwhittemore]

Using Insiders, just to be certain (impacts current release also)

• VSCode Version: 1.26.0-insider
• OS Version: macOS 10.13.6

Steps to Reproduce:
With a completely virgin install of macOS

1. At a system terminal, set $PATH to something interesting, then launch code:

extra-super-virgin-macos:~ alexw$ export PATH="/Users/alexw/Desktop:$PATH"
extra-super-virgin-macos:~ alexw$ echo $PATH
/Users/alexw/Desktop:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
extra-super-virgin-macos:~ alexw$ code-insiders --disable-gpu

2. In the vscode integrated terminal, show $PATH:

extra-super-virgin-macos:~ alexw$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alexw/Desktop

That is to say, somehow, at some point, Code is taking the first item(s?) in my PATH and tacking them on the end instead, which, of course, alters the entire behavior of any shells with the altered version.

Does this issue occur when all extensions are disabled?: Yes (none installed at all)

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Path issues with -i (#30847)

[alexwhittemore]

Does not seem to be related to 30847.

[ramya-rao-a]

What do you see when you type process.env['PATH'] in the console? Help -> Toggle Developer Tools -> Console

[alexwhittemore]

The same- whatever my base system path is, with whatever prepended customizations somehow appended instead.

[Tyriar]

@alexwhittemore how did you launch VS Code? Also what's your PATH when you run bash -l inside your system terminal?

[alexwhittemore]

In a system terminal (looks like VMWare did something since last I was testing this):

Alexs-MBP-2018:~ 
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public
Alexs-MBP-2018:~ 
› bash -l
Alexs-MBP-2018:~ 
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public

typically I'd workon my_env; code .

When I do that, I get this in the Code terminal:

Alexs-MBP-2018:~/Development/Python/Plotter
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Users/alexw/.virtualenvs/py3_plotter/bin
Alexs-MBP-2018:~/Development/Python/Plotter
› bash -l
Alexs-MBP-2018:~/Development/Python/Plotter
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Users/alexw/.virtualenvs/py3_plotter/bin

I'm not quite sure what bash -l is supposed to accomplish; it doesn't seem to be doing anything interesting.

EDIT: I realize now what it does, but anyway, the child shell seems to launch with the same environment (which I'd expect).

[Tyriar]

@alexwhittemore can you also try this?

echo $PATH
export PATH="/Users/alexw/Desktop:$PATH"
bash -l
echo $PATH

I'm trying to identify whether code is running your login shell script again which is pushing /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin to the front of $PATH.

Relevant code pointer:

https://github.com/Microsoft/vscode/blob/5e5f6fc6ec785a602f1444500264f18d136b5e87/src/vs/code/node/shellEnv.ts#L78-L95

[alexwhittemore]

Ohhhhhhh interesting. That certainly looks to be what's happening:

Alexs-MBP-2018:~ 
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public
Alexs-MBP-2018:~ 
› export PATH="/Users/alexw/Desktop:$PATH"
Alexs-MBP-2018:~ 
› bash -l
Alexs-MBP-2018:~ 
› echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Users/alexw/Desktop

Also: oooh pretty highlighting. TIL.

[segevfiner]

Related/duplicate of #55144 ? (Which I made a PR for that you're welcome to test)

[alexwhittemore]

@segevfiner I'm not sure about duplicate, but it sounds like it's related enough that perhaps your PR fixes it?

I've never compiled so much as an electron hello world, so I'm not sure how to go about testing your PR myself, but if I get a little more time than I have now, I'll look into it.

In the mean time, if you'd be willing to try it for me, the test case is pretty straightforward:

(system terminal:)

$ export PATH=~/Desktop:$PATH
$ echo $PATH
# should spit back "/Users/You/Desktop:/rest/of/your/PATH"
$ code .

(at code integrated terminal:)

$ echo $PATH
# if failed:
# /rest/of/your/path:/Users/You/Desktop
# If fixed:
# /Users/You/Desktop:/rest/of/your/path

[alexwhittemore]

Hmm @segevfiner I just noticed a behavior that does make this seem highly related - if I launch code . from a separate terminal NOT in a virtualenv, code adopts the environment of the first-opened window. In my case, that one was opened inside a virtualenv, and has a mangled path and the $VIRTUAL_ENV set.

[Tyriar]

@alexwhittemore I think given that bash -l repros this, you should be able to fix this by tweaking your launch scripts, you want to make them idempotent (don't break things if they're run multiple times).

[alexwhittemore]

I think I'm confused - what launch scripts? And what about them would take a perfectly fine path and do this nonsense to it?

EDIT: also, since this is reproducible on a completely stock, out of the box installation of macOS, are you suggesting that this is an issue with a stock OS configuration?

EDIT EDIT: HMMMMM.

Alexs-MBP-2018:~ 
› cat /etc/profile
# System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then
	eval `/usr/libexec/path_helper -s`
fi

if [ "${BASH-no}" != "no" ]; then
	[ -r /etc/bashrc ] && . /etc/bashrc
fi

Could this be the cause of my anguish? Guess I need to read up on path_helper. That looks to be the only thing explicitly to do with $PATH (nothing interesting in /etc/bashrc)

EDIT EDIT EDIT:
I'm not decided, but if the culprit is path_helper, does it just happen to be the case that I'm 1) the only one who uses Code this way on mac or 2) the only one annoyed that it just happens to not work the same on mac as it does on Windows and Linux? I still haven't read up enough to know what's actually going on, but I can already see some "un-screw-up-my-PATH" scripts, so I guess it's not just Code that's impacted? https://gist.github.com/erluko/4242255

Anyway it surprises me greatly that this is the first time I, or apparently anyone, has run into this if the cause is something introduced in 2012...

Anyway thank you for putting me on the right path, at the least!

[Tyriar]

Linux handles the profile and rc scripts differently and imo in a superior way, Windows is completely different so I do think this is a mac only problem. Here are the main differences:

• Linux will run your profile script (ie. the login script) when you login to the system, when you launch a terminal Linux will run your .bashrc file
• macOS will run your profile script when you launch a terminal

This caused a whole bunch of headaches a long time ago and I eventually caved and make macOS launch a login script within the terminal #20145 (comment), but that causes a whole bunch of other issues.

I don't normally do what you're trying to do, but I'm sure there's a proper way you're meant to do it. I also recommend reading up on the difference between .bashrc/.bash_profile and login shells/non-login shells.

[Tyriar]

Related: #55194

[alexwhittemore]

So I think the end result here is that two things are conspiring against my "virtualenv + code ." workflow, making it nowhere near as effective on Mac as on Win or Linux:

1. path_helper does awful things to a pre-existing $PATH variable, re-ordering PATH for any shell opened as login ("Why ever would you want your PATH to have the same order?! I'm a LOGIN shell! The original shell! The SUPREME shell!"). I can't simply disable path_helper, since other things expect it to be functional. And therefore it will be a pain in my neck forever, so long as Code needs to start in a login shell.

I can work around that at least a couple different ways - set a breadcrumb like OLD_PATH when I activate a virtualenv, and restore that to $PATH in bashrc. Or detect custom path items and blindly restore them to the front of the line. Or, application-specific, detect VIRTUAL_ENV and reactivate it blindly.

But then despite any of those, I still run into

2. Code windows don't support independent, differing environments. Subsequently-opened windows always inherit environment variables from the existing windows, and that will forever break, for example, working on two different virtualenvs in two different windows.

So I guess the Code workflow is just inherently worse on Mac than Windows, until there's first-class support for virtualenvs in the vscode Python plugin :(

[Tyriar]

I'd recommend joining the discussion over at #15452, also for Python specifically I'm not sure if the python extension has a nice workaround for handling virtualenv or not https://github.com/Microsoft/vscode-python

[alexwhittemore]

also for Python specifically I'm not sure if the python extension has a nice workaround for handling virtualenv or not

My understanding is, at this juncture, it's a discussion-in-progress.

[segevfiner]

I'd recommend joining the discussion over at #15452, also for Python specifically I'm not sure if the python extension has a nice workaround for handling virtualenv or not https://github.com/Microsoft/vscode-python

They have a separate "Create Terminal" command that creates a terminal with the active Python environment. But due to API limitations, this is a separate command and as such by default terminals are created using VS Code's environment via the stock "Create Terminal" command.

[Tyriar]

@segevfiner sure, you could replace the keybinding though if it's all you want to use:

{ "key": "ctrl+`", "command": "thepythoncommand" }

You can even make this the default only when you have a Python file opened:

{ "key": "ctrl+`", "command": "thepythoncommand", "when": "editorLangId == 'python'" }