Built-in terminal fails to properly initialize PATH with path_helper on Darwin

[geoff-nixon]

• VSCode Version: Code - Insiders 1.7.0-insider (5dd716e, 2016-10-13T07:56:04.286Z)
• OS Version: Darwin x64 15.6.0
• Extensions: None

Steps to Reproduce:

1. Nothing.
2. Be be missing important elements from the default $PATH.

So I literal decided to give this Editor a shot maybe 4 minutes ago, so bit of a rocky start 🙀 but at least I can tell you what's up!

On Darwin, the default _SC_PATH (sysconf PATH) is augmented (for all users, including root) by the terminal with the paths contained in the file /etc/paths and in files within /etc/paths.d. This is done by sourcing the shell with the output /usr/libexec/path_helper, immediately prior to the shell beginning its own initialization routines (sourcing .[bash][rc|_profile], etc. I'm not 100% sure on the implementation but between Terminal.app and especially iTerm (it being open source) it shouldn't be too hard to figure out the "exact right way" to do this.

This is extremely important, as paths "as trivial" as /usr/local/bin enter the PATH this way;
getconf PATH is only /usr/bin:/bin:/usr/sbin:/sbin!

Doing a 10 second search, this is probably also #13671, and I'd guess a few other issues you have open as well.

Cheers,
G

[Tyriar]

@geoff-codes so you're saying the $PATH in the integrated terminal differs from that in Terminal.app? Can you try opening dev tools (Help > Toggle Developer Tools), open the console, run process.env.PATH and compare that against the PATH variable in Terminal.app and the integrated terminal? That will help narrow down whether it's an issue with the editor's env or if it's the terminal's doing.

[nilstgmd]

@Tyriar I have the same problem where my Go installation isn't found when opening Code from Find/Spotlight.

> process.env.PATH
< "/usr/bin:/bin:/usr/sbin:/sbin"

Opening Code from the terminal (iTerm2 in my case) gives me this output:

> process.env.PATH
< "/usr/local/sbin:/usr/local/bin:/Users/meder/.cargo/bin:/Users/meder/go/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin:/Users/meder/.cargo/bin:/Users/meder/go/bin:/usr/local/m-cli:/Users/meder/dcos/bin:/usr/local/m-cli"

> code --version
1.6.1
9e4e44c19e393803e2b05fe2323cf4ed7e36880e
> sw_vers -productVersion                                                                                                                                                                                                                                                
10.11.6

Cheers.

[Tyriar]

You can set the terminal to launch as a login process, this would probably solve these issues as it forces ~/.bash_profile to run when the terminal is launched. Add this to your settings:

  "terminal.integrated.shell.osx": "/bin/bash",
  "terminal.integrated.shellArgs.osx": ["-l"]

Let me know if that doesn't solve your problem.

[peabnuts123]

This fixed my problem but I don't know if it's necessary to load my full bash profile in order to ensure PATH is correct (for example, my integrated terminal now runs tmux, lol). Is this a bug?

Without the -l arg my $PATH is the same as above (/usr/bin:/bin:/usr/sbin:/sbin), and lots of things break because they can't be found (dotnet for example). Also running OSX

[peabnuts123]

As mentioned in #21655 simply having tmux invoked from my .bash_profile caused this issue for me, despite not passing -l into the terminal as an argument. If others are having this issue, check your .bash_profile for related things. I don't know why this affects vscode.

[Tyriar]

@peabnuts123 I actually get this quite a bit so I wrote up a saved reply in GH which you can read below, including the reasons for the decision.

---

This is happening because we don't run the integrated terminal as a login shell by default. You will need to add the following to launch bash as a login shell:

// macOS:
"terminal.integrated.shellArgs.osx": [ "-l" ]
// Linux
"terminal.integrated.shellArgs.linux": [ "-l" ]

You could also solve this by moving the relevant parts of your ~/.bash_profile to your ~/.bashrc file which is run for non-login shells.

More information:

• Official documentation
• Reasons for this default behavior

[peabnuts123]

I'm sorry, I don't see how that's really related. I understand that the integrated terminal is not a login shell; that's WHY it's spooky-action to have the contents of my .bash_profile affect it. Also, a lot of OSX users don't even have a .bashrc at all because bash runs as a login shell on OSX by default.