PATH issues with Fish shell on macOS
NinoFloris opened this issue · comments
So while having a problem PATH related I created an issue in the omnisharp vscode repo about this. However right after doing a quick chsh /bin/bash and a restart of vscode my suspicions were right and now I'm coming back to you guys.
The issue in omnisharp vscode:
dotnet/vscode-csharp#1259
Previous fix I'm pointing to:
#8434
Seems that somehow this fix regressed again. Or my shell does even more effort to break it...
I'm still using fish with powerline as my shell and it seems to break the env (and in turn PATH) parsing again.
I propose a change to the PATH resolution strategy for OSX:
- Run
path_helperfor an initial view of an ok customizable PATH of an OSX installation. It gathers all paths from the file/etc/pathsand paths in files in/etc/paths.dlike the one fordotnet. It outputs a PATH string of these paths. - Do the hacky thing with reading out a login shell's env and parsing the PATH from it.
- Use the hacky output if there is actually any. Every login shell runs
path_helperbut also includes all user customizations to PATH from say .bash_profile. - If the shell is so custom it breaks the hacky way of fishing out the PATH then just use the
path_helperoutput.
This way the result will at least always be a working env (for say quite integrated things like spawning a dotnet process for doing a restore).
Because everyone should be able to expect that after installing a pkg like the dotnet cli vscode (and its extensions) can always find and work with it seamlessly.
dotnet --info output:
.NET Command Line Tools (1.0.0-rc4-004849)
Product Information:
Version: 1.0.0-rc4-004849
Commit SHA-1 hash: 7dcefb5076
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.0-rc4-004849
VS Code version: 1.10.0-insider
C# Extension version: 1.7.0
@weinand @joaomoreno would I be correct in assuming that if VS Code fixes this issue, the extra environment settings will automatically propagate to the C# extension processes?
Did this really regress for you? Was it working before? In which version did it stop working?
cc @jrieken
@gregg-miskelly Yes as vscode is the host process from where you spawn new dotnet processes a shell like PATH will then allow it to actually find dotnet. Also each child process gets the env of the parent. That's why starting vscode from a terminal succeeds as a work-around.
@joaomoreno I picked up a new macbook a little while ago, copied over all my old dotfiles for fish etc and installed vscode. To my knowledge it didn't work since I got this new macbook.
A lot of extensions expect PATH to be filled like a shell so once this is fixed things will start working again. Whether such widespread expecatations are a good or bad thing is something I leave up to you.
OK, is PATH the only variable that is wrong, or are there other variables missing from Code's window?
You can figure this out by running F1, Developer Tools and then in the Console run process.env.
What version do you currently have, btw?
Everything in the env seems incorrect, no OMF keys, default path and missing all other customizations.
Tested with insiders latest and normal 1.10.1
Can you also try this in the dev tools console and compare with the previous output: process.lazyEnv.then(v => console.log(v))
@jrieken, exactly the same. @joaomoreno sadly no
Is $SHELL actually pointing to the right shell that you are using? We do this which is running node such that it dumps the env from the default shell. So, if the shell-variable points to the correct shell I would assume that node gets the correct variables inherited and that we then use the right variables too
const command = `'${process.execPath}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
const child = cp.spawn(process.env.SHELL, ['-ilc', command], {
detached: true,
stdio: ['ignore', 'pipe', process.stderr],
env
});If 1.9 doesn't work correctly, this is not a regression.
If you open the Developer Tools and run this in the console, what comes back?
(() => {
const electron = require('electron').remote.process.execPath;
const cp = require('child_process');
const mark = 'MARK123';
const env = Object.assign({}, process.env, {
ELECTRON_RUN_AS_NODE: '1',
ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
detached: true,
stdio: ['ignore', 'pipe', process.stderr],
env,
encoding: 'utf8'
});
console.log(result.stdout);
})();@jrieken yes, just did a which fish and compared it with an echo of SHELL identical paths
@joaomoreno it returns undefined
running the command directly
fish -ilc "'/Applications/Visual Studio Code.app/Contents/MacOS/Electron' -p '"MARK123" + JSON.stringify(process.env) + "MARK123"'"
Opens a new file in vscode with no contents, so it seems there is no issue with the command persé but the output is still incorrect
Nvm running this on my old laptop gives the same results, don't really know what -p does ;)
@NinoFloris It returns undefined, but should print something else in the console after 1 second or so. Nothing gets printed?
Running it standalone, you need the right env:
ELECTRON_RUN_AS_NODE=1 ELECTRON_NO_ATTACH_CONSOLE=1 fish -ilc "'/Applications/Visual Studio Code.app/Contents/MacOS/Electron' -p '"MARK123" + JSON.stringify(process.env) + "MARK123"'"
Nope from within vscode it returns nothing.
running
env ELECTRON_RUN_AS_NODE=1; env ELECTRON_NO_ATTACH_CONSOLE=1; fish -ilc "'/Applications/Visual Studio Code.app/Contents/MacOS/Electron' -p '"MARK123" + JSON.stringify(process.env) + "MARK123"'"
returns the right things!
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.TBtCF6pWmO/Render
COLORFGBG=15;0
HOME=/Users/nfloris
ITERM_PROFILE=Default
ITERM_SESSION_ID=w3t0p0:BAF42606-4339-4892-A1C5-40759BC537AE
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LC_CTYPE=UTF-8
LOGNAME=nfloris
OMF_CONFIG=/Users/nfloris/.config/omf
OMF_PATH=/Users/nfloris/.local/share/omf
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.node/bin:~/.terraform:~/.composer/vendor/bin
PWD=/Users/nfloris
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.TakpSw68bL/Listeners
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.0.13
TERM_SESSION_ID=w3t0p0:BAF42606-4339-4892-A1C5-40759BC537AE
TMPDIR=/var/folders/8n/pxszz5w97ml_9t3my9y16jpr0000gp/T/
USER=nfloris
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
__CF_USER_TEXT_ENCODING=0x1F6:0x0:0x0
ELECTRON_RUN_AS_NODE=1
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.TBtCF6pWmO/Render
COLORFGBG=15;0
HOME=/Users/nfloris
ITERM_PROFILE=Default
ITERM_SESSION_ID=w3t0p0:BAF42606-4339-4892-A1C5-40759BC537AE
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LC_CTYPE=UTF-8
LOGNAME=nfloris
OMF_CONFIG=/Users/nfloris/.config/omf
OMF_PATH=/Users/nfloris/.local/share/omf
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.node/bin:~/.terraform:~/.composer/vendor/bin
PWD=/Users/nfloris
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.TakpSw68bL/Listeners
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.0.13
TERM_SESSION_ID=w3t0p0:BAF42606-4339-4892-A1C5-40759BC537AE
TMPDIR=/var/folders/8n/pxszz5w97ml_9t3my9y16jpr0000gp/T/
USER=nfloris
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
__CF_USER_TEXT_ENCODING=0x1F6:0x0:0x0
ELECTRON_NO_ATTACH_CONSOLE=1
I can't be much help but I can confirm that using zsh I experience this issue with cargo run.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"command": "cargo",
"isShellCommand": true,
"args": ["run"],
"showOutput": "always",
"isBuildCommand": true
}
This JSON produces the errror
Failed to launch external program cargo run.
spawn cargo ENOENT
Although chsh to /bin/bash didn't fix the issue for me after relogging.
(() => {
const electron = require('electron').remote.process.execPath;
const cp = require('child_process');
const mark = 'MARK123';
const env = Object.assign({}, process.env, {
ELECTRON_RUN_AS_NODE: '1',
ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
console.log(command);
console.log(process.env.SHELL);
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
detached: true,
stdio: ['ignore', 'pipe', process.stderr],
env,
encoding: 'utf8'
});
console.log(result);
console.log(result.stdout);
})();Added a few more console.log calls... let me know what comes out.
I use the fish shell and have the exact same problem. The above snippet seems to return correct output:
'/Applications/Visual Studio Code.app/Contents/MacOS/Electron' -p '"MARK123" + JSON.stringify(process.env) + "MARK123"'
/usr/local/bin/fish
(The console.log(result); line doesn't paste well)
MARK123{"ANDROID_HOME":"/Users/john/Library/Android/sdk","Apple_PubSub_Socket_Render":"/private/tmp/com.apple.launchd.pwMyJ2Vo9p/Render","CLICOLOR":"1","COLORFGBG":"15;0","DISPLAY":"/private/tmp/com.apple.launchd.O7WsAbsJjt/org.macosforge.xquartz:0","ELECTRON_NO_ATTACH_CONSOLE":"1","ELECTRON_RUN_AS_NODE":"1","GOOGLE_API_KEY":"AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q","GOPATH":"/Users/john/go","HOME":"/Users/john","HOMEBREW_NO_ANALYTICS":"1","ITERM_PROFILE":"Default","ITERM_SESSION_ID":"w0t0p0:DFD238F3-D951-4C33-AFBC-6F8095A42E87","JAVA_HOME":"/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home","LC_ALL":"en_US.UTF-8","LC_CTYPE":"en_US.UTF-8","LOGNAME":"john","LSCOLORS":"GxFxCxDxBxegedabagaced","OMF_CONFIG":"/Users/john/.config/omf","OMF_PATH":"/Users/john/.local/share/omf","PATH":"/usr/local/sbin:/Users/john/bin:/Users/john/go/bin:/Users/john/.rvm/bin:/usr/local/sbin:/Users/john/bin:/Users/john/go/bin:/Users/john/.rvm/bin:/Users/john/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin","PWD":"/Users/john","SHELL":"/usr/local/bin/fish","SHLVL":"4","SSH_AGENT_PID":"16312","SSH_AUTH_SOCK":"/private/tmp/com.apple.launchd.HrWUzNnMvL/Listeners","TERM":"xterm-256color","TERM_PROGRAM":"iTerm.app","TERM_PROGRAM_VERSION":"3.0.13","TERM_SESSION_ID":"w0t0p0:DFD238F3-D951-4C33-AFBC-6F8095A42E87","TMPDIR":"/var/folders/lv/5rvd6xqx20d8h0pych18kz8r0000gn/T/","USER":"john","VSCODE_CLI":"1","VSCODE_IPC_HOOK":"/Users/john/Library/Application Support/Code/1.10.1-main.sock","VSCODE_NLS_CONFIG":"{\"locale\":\"en-gb\",\"availableLanguages\":{}}","VSCODE_NODE_CACHED_DATA_DIR_30754":"/Users/john/Library/Application Support/Code/CachedData","VSCODE_PID":"30754","VSCODE_SHARED_IPC_HOOK":"/Users/john/Library/Application Support/Code/1.10.1-shared.sock","XPC_FLAGS":"0x0","XPC_SERVICE_NAME":"0","__CF_USER_TEXT_ENCODING":"0x1F5:0x0:0x0"}MARK123
In particular, process.env.PATH is correctly populated. The only thing I can think of that could be a problem is that in fish, the $PATH parts are separated differently:
> echo $PATH
/usr/local/sbin /Users/john/bin /Users/john/go/bin /Users/john/.rvm/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /opt/X11/bin /usr/local/MacGPG2/bin /Library/TeX/texbin
Ok took some time to diagnose the issue myself, fish goes belly up when -i (interactive) in -ilc is used while no stdin is connected.
If I just pipe through stderr to inspect it in the process object this is the error shown
"stty: stdin isn't a terminal"
So the fix is easy, change
stdio: ['ignore', 'pipe', process.stderr],
to
stdio: ['pipe', 'pipe', process.stderr],
This also explains why I could get the command to work on the terminal as a stdin is surely connected in that case ^_^
That doesn't seem to work for me - but then, my problem seems to occur not when examining the shell environment (as I do have a correctly populated process.env.PATH), but only when launching executables such as sh.
Thanks for the fix @NinoFloris, will verify and push it.
@sietseringers I'm not entirely sure I understand your problem or whether it's an issue with Code itself. Can you create a separate issue and ping me in it?
On OSX, VSCode 1.10.2, $PATH variable has started being /usr/bin:/bin:/usr/sbin:/sbinand now heaps of stuff doesn't work (like dotnet). Is this fix going to resolve this for me? Invoking VScode from terminal fixes the issue.
you could try running the insiders build (it's nightly so the fix is in there)
Latest Insiders build still showing $PATH as /usr/bin:/bin:/usr/sbin:/sbin
@peabnuts123 could you try to run something via cmd+shift+p toggle developer tools and pasting it into the console?
(() => {
const electron = require('electron').remote.process.execPath;
const cp = require('child_process');
const mark = 'MARK123';
const env = Object.assign({}, process.env, {
ELECTRON_RUN_AS_NODE: '1',
ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
console.log(command);
console.log(process.env.SHELL);
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
detached: true,
stdio: ['ignore', 'pipe', process.stderr],
env,
encoding: 'utf8'
});
console.log(result);
console.log(result.stdout);
})();If you can post the output of this that would help everyone
Oh, weird. I accidentally fixed this issue between then and now. I went to run your script but my PATH was correct in both the insiders and regular builds of VSCode.
I have a check in my .bash_profile that invokes tmux if appropriate. Disabling this check fixed all the things, despite not passing -l as an argument to the terminal in vscode (which previously would fix things but meant tmux would run my interactive terminal, lol).
Here is my full .bash_profile:
export NVM_DIR="/Users/jeff/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
#if command -v tmux>/dev/null; then
# [[ ! $TERM =~ screen ]] && [ -z $TMUX ] && exec tmux
#fi
Commenting out the second section fixes everything.
Nice, good to hear!
Do you think this warrants a separate issue? My .bash_profile should not really be affecting vscode like that unless I pass something like -l to the integrated Terminal, right?
Well if you look at how vscode captures the shell's env it does this by starting a shell with -ilc
So yes it's very intended behavior that your .bash_profile (or any other login script for other shells) is being executed.
The idea behind it being that most people (like me) have developer related PATH entries in their login profiles and we'd like vscode to pick those up and let the integrated terminal feel just like our standalone one
Ah i see. That makes sense. It is a bit opaque, but logical... Though now I don't know what was messing with my PATH
@joaomoreno what's the reasoning behind fetching the environment from a login shell? Everything I've read on the subject suggests that this is not how the system was designed and we should instead be encouraging people to set up their environment in either their ~/.profile or ~/.bashrc. See #13701 (comment) and #20145 (comment)
I don't think anything gets solved by putting stuff in ~/.bashrc. Double clicking an app still bypasses bash completely, thus the environment won't be there.
Don't know about ~/.profile.
~/.profileruns when you launch a login shell (eg. you log into the OS)~/.bash_profileruns when you run bash as a login shell (eg. ssh to a terminal)~/.bashrcruns when you runbash(unless you specify the file to source via CLI args)
Apparently I might be wrong about the ~/.profile thing on Mac http://unix.stackexchange.com/a/119675/115410
@joaomoreno after reading about this I've made the default run as a login shell on macOS f574b11
I don't think it makes sense to run as a login shell on Linux though, why would we want to run the bash specific ~/.bash_profile within VS Code if ~/.profile has already set up the environment.
I wasn't aware of ~/.profile. We should then fix it.
On the other hand, this will break people since some tools, such as nvm, install themselves into .bashrc. They need to move that line to .profile. Not sure if it will be worth the hassle.
@joaomoreno from a purist perspective I want it changed... But yeah, probably not the best idea for that reason 😅
Verified by doing the following on macOS:
-
Install homebrew
-
Install fish
-
Install dotnet core cli
-
Set fish to default shell
-
Quit Terminal.app
-
Launch Terminal.app to ensure fish starts and finds dotnet on path
-
Quit VS Code
-
Launch VS Code
-
Open dev tools
-
Run
process.envin console to verify the dotnet CLI shows up:/Users/daimms/.npm-packages/bin:/Users/daimms/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet"
Let me know if that doesn't verify completely 😃
How have you done step 4. Set fish to default shell? See my above configuration:
if command -v tmux>/dev/null; then
[[ ! $TERM =~ screen ]] && [ -z $TMUX ] && exec tmux
fiin my .bash_profile
Well your default shell you would change with chsh [-s shellpath]
I see. I don't think that 100% validates it, as I am just running tmux from my normal shell (in my instance). Is this just verifying that adding the -l arg fixes things? I can re-test that later tonight if needed
@peabnuts123 yes I just used chsh, I don't have my Mac on my right now so I can't verify again. We'll likely release first. Have you verified it in Insiders?
Will attempt to verify today but my Macbook seems to have crapped out this morning ........................................ >_>
We're going to have to revert this fix, since it breaks many other people #23639
@NinoFloris Can you show me how your machine is configured? What's your fish version? What's its configuration & plugins? I want to reproduce your issue.
FYI my Macbook did in fact die the other day and so I no longer have a copy of OSX to verify any of this on for another week or two. Maybe after then I will get serious and actually submits some PRs or something...
I had some issue and made a helper script. I put it in my path and then when I start a new project I only need to run it once. It install a fake node, npm, nvm, and .nvmrc. Then everything can be run from the project root directory.
#!/bin/bash -e
NVM_EXEC=$HOME/.nvm/nvm-exec
NODE=$(which node)
NPM=$(which npm)
export NODE_VERSION=$(${NODE} --version)
NPM_VERSION=$(${NPM} --version)
echo $NODE_VERSION >.nvmrc
readlink -f .vnmrc
if [ ! -d ".bin" ]; then
mkdir -p .bin
fi
cd .bin &&
echo "${NODE} \$@" >node &&
echo "${NPM} \$@" >npm &&
echo "${NVM_EXEC} \$@" >nvm-exec &&
chmod +x node npm nvm-exec
echo "node: ${NODE_VERSION} npm: ${NPM_VERSION}"
Sample task:
{
"version": "0.1.0",
"options": {
"cwd": "${workspaceRoot}"
},
"command": "./.bin/node",
"isShellCommand": true,
"args": [
"--version"
],
"showOutput": "always"
}
In case it helps, I ran into this issue because I had weird stuff on the end of my PATH variable, an error message from a bad rvm install.
After upgrading to 1.12.1 VS Code would no longer find anything on my path, cleaning up my PATH resolved it. Maybe something changed recently in the way PATH is parsed. Running the script above in development tools would just silently fail.
I'm using zsh and nvm on macOS.
Having the same issue in 1.12.1, these issues did not exist in 1.12.0. Errors on phpcs, node, npm, flow... basically anything from any path.
While I use zsh and nvm, my paths are also set for bash because XCode needs them. I have verified that the paths are correctly set in both shells.
Opening code from the terminal does not exhibit the behaviour.
@kriscarle @victoriafrench Open the Developer Tools and run:
(() => {
const electron = require('electron').remote.process.execPath;
const cp = require('child_process');
const mark = 'MARK123';
const env = Object.assign({}, process.env, {
ELECTRON_RUN_AS_NODE: '1',
ELECTRON_NO_ATTACH_CONSOLE: '1'
});
const command = `'${electron}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`;
console.log(command);
console.log(process.env.SHELL);
const result = cp.spawnSync(process.env.SHELL, ['-ilc', command], {
detached: true,
stdio: ['ignore', 'pipe', process.stderr],
env,
encoding: 'utf8'
});
console.log(result);
console.log(result.stdout);
})();What comes out?
@joaomoreno I seem to be having this path issue as well.
macOS: 10.12.4 (16E195)
fish: version 2.5.0
vscode: 1.12.1
from fish:
➤ echo $PATH
/usr/local/Cellar/node/7.9.0/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin
from bash:
bash-3.2$ echo $PATH
/usr/local/Cellar/node/7.9.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
And here is what happens when I start VSCode or reload the window.
Edit:
"env": {
"TMPDIR": "/var/folders/r2/n0hjdgyj36n0b5zmtrk2bw1h0000gp/T/",
"__CF_USER_TEXT_ENCODING": "0x1F6:0x0:0x0",
"HOME": "/Users/sorahn",
"SHELL": "/usr/local/bin/fish",
"Apple_PubSub_Socket_Render": "/private/tmp/com.apple.launchd.xN7SO0DPRv/Render",
"SSH_AUTH_SOCK": "/private/tmp/com.apple.launchd.GW1hdcrv33/Listeners",
"PATH": "/usr/bin:/bin:/usr/sbin:/sbin",
"LOGNAME": "sorahn",
"XPC_SERVICE_NAME": "com.microsoft.VSCode.3908",
"USER": "sorahn",
"SECURITYSESSIONID": "186a7",
"XPC_FLAGS": "0x0",
"GOOGLE_API_KEY": "AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q",
"LC_NUMERIC": "C",
"VSCODE_NLS_CONFIG": "{\"locale\":\"en-us\",\"availableLanguages\":{}}",
"VSCODE_NODE_CACHED_DATA_DIR_27655": "/Users/sorahn/Library/Application Support/Code/CachedData/f6868fce3eeb16663840eb82123369dec6077a9b",
"VSCODE_PID": "27655",
"VSCODE_IPC_HOOK": "/Users/sorahn/Library/Application Support/Code/1.12.1-main.sock",
"ELECTRON_RUN_AS_NODE": "1",
"ELECTRON_NO_ATTACH_CONSOLE": "1"
},
tried to help format it a bit and removed my login name for security purposes.
'/Applications/Visual Studio Code.app/Contents/MacOS/Electron' -p '"MARK123" + JSON.stringify(process.env) + "MARK123"'
MARK123 : {
"TMPDIR" : "/var/folders/sm/40nrpg3n1kd9vz9d5gsjsdfm0000gn/T/",
"__CF_USER_TEXT_ENCODING" : "0x1F5:0x0:0x0",
"SHELL" : "/bin/zsh",
"HOME" : "/Users/XXX",
"Apple_PubSub_Socket_Render" : "/private/tmp/com.apple.launchd.pi584QisyD/Render",
"SSH_AUTH_SOCK" : "/private/tmp/com.apple.launchd.oo7n6UzM8s/Listeners",
"PATH" : "/Users/XXX/.sdkman/candidates/gradle/current/bin:/Users/XXX/.rvm/bin:/Users/XXX/.nvm/versions/node/v6.10.3/bin:/Users/XXX/.nvm/versions/node/v6.10.3/lib/node_modules:/usr/local/lib/node_modules:/Users/XXX/.nvm/versions/node/v6.10.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/XXX/.nvm/versions/node/v6.10.3/bin:/usr/local/opt/android-sdk:/usr/local/opt/android-sdk/tools:/usr/local/opt/android-sdk/bin:/usr/local/opt/android-sdk/platform-tools:/usr/local/bin/mongo",
"LOGNAME" : "XXX",
"XPC_SERVICE_NAME" : "com.microsoft.VSCode.238892",
"USER" : "XXX",
"XPC_FLAGS" : "0x0",
"GOOGLE_API_KEY" : "AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q",
"LC_NUMERIC" : "C",
"VSCODE_NODE_CACHED_DATA_DIR_32314" : "/Users/XXX/Library/Application Support/Code/CachedData/f6868fce3eeb16663840eb82123369dec6077a9b",
"VSCODE_NLS_CONFIG" : {
"locale" : "en-us",
"availableLanguages": {}
},
"VSCODE_PID" : "32314",
"VSCODE_IPC_HOOK" : "/Users/XXX/Library/Application Support/Code/1.12.1-main.sock",
"ANDROID_HOME" : "/usr/local/opt/android-sdk",
"ANDROID_PLATFORM" : "/usr/local/opt/android-sdk/tools:/usr/local/opt/android-sdk/bin:/usr/local/opt/android-sdk/platform-tools",
"GRADLE_HOME" : "/Users/XXX/.sdkman/candidates/gradle/current",
"JAVA_HOME" : "/Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home",
"LESS" : "-R",
"LSCOLORS" : "Gxfxcxdxbxegedabagacad",
"MANPATH" : "/Users/XXX/.nvm/versions/node/v6.10.3/share/man:/usr/share/man:/usr/local/share/man:/Library/Frameworks/Mono.framework/Versions/Current/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man",
"MONGO_PATH" : "/usr/local/bin/mongo",
"NVM_BIN" : "/Users/XXX/.nvm/versions/node/v6.10.3/bin",
"NVM_CD_FLAGS" : "-q",
"NVM_DIR" : "/Users/XXX/.nvm",
"NVM_IOJS_ORG_MIRROR" : "https://iojs.org/dist",
"NVM_NODEJS_ORG_MIRROR" : "https://nodejs.org/dist",
"NVM_PATH" : "/Users/XXX/.nvm/versions/node/v6.10.3/lib/node",
"OLDPWD" : "/",
"PAGER" : "less",
"PWD" : "/",
"SDKMAN_CANDIDATES_DIR" : "/Users/XXX/.sdkman/candidates",
"SDKMAN_CURRENT_API" : "https://api.sdkman.io/2",
"SDKMAN_DIR" : "/Users/XXX/.sdkman",
"SDKMAN_LEGACY_API" : "https://api.sdkman.io/1",
"SDKMAN_PLATFORM" : "Darwin",
"SDKMAN_VERSION" : "5.1.4+78",
"SHLVL" : "0",
"ZSH" : "/Users/XXX/.oh-my-zsh",
"_" : "/Applications/Visual Studio Code.app/Contents/MacOS/Electron",
"ELECTRON_RUN_AS_NODE" : "1",
"ELECTRON_NO_ATTACH_CONSOLE" : "1",
"LC_CTYPE" : ""
}@joaomoreno Please pretty please I'm asking you, after yet another email of people that actually found the cause of their problems and then would actually write a reply (which is just a small percentage of people that have these issues)
Please at least implement /etc/paths.d fallback behaviour for osx. When PATH enumeration does not work it breaks almost every conceivable case of vscode language server integration behavior ranging from your core group of users (node and npm issues) to your companies own language servers for dotnet.
This really needs a little extra escalation
I've encountered the issue again after a few relaunches of VS Code, and I think I've tracked down why version 1.12.1 started causing this for some of us. At the top of the development console is an error renderer did not receive lazyEnv in time which was introduced in 1.12.1 by f3ffc2e
This adds a 2000 ms timeout when retrieving the shell to fix a hang issue #24435. The problem for me is that with nvm, rvm, lots of Oh My Zsh plugins, etc. my shell can take more than 2 seconds to load... mildly annoying but not to the point that I've ever tried to fix it.
Maybe a quick solution is to increase the timeout a bit, out of "mildly annoying" range? :)
Seeing the same renderer did not receive lazyEnv in time warning. I don't have a lot of zsh plugins but I do initialize docker which takes a second or two.
renderer did not receive lazyEnv in time + 1
zsh + omzsh plugins + tmux + tmux plugins + nvm etc. taking around 5-8 seconds to load on my machine.
Excellent. Many thanks for the renderer did not receive lazyEnv in time finding, guys.
@kriscarle @victoriafrench @burakcan You three should stop commenting on this issue and move over to #26438. Your issue isn't the same as @NinoFloris.
@NinoFloris last I heard from you was:
I will double check it later but it was with the latest fish version, and plugins are not
relevant. Fish will just crash with an error on stderror about an
unconnected stdin if the stdin of the node process is not connected like it was
I was waiting on more details from you. Let me look into that paths.d solution.
I've having the same issue with 1.12.2 and Fish 2.5.0.
With the code snippet above I get no output, i.e. result.stdout is an empty string.
However, it works when I remove the -i flag from the fish invocation, i.e. run fish -lc instead fish -ilc. In other words, result.stdout contains my environment variables when I change the code to run a non-interactive shell. I do not know what's causing this behaviour, perhaps fish expects an attached TTY when running interactively.
It seems to me though that vscode should use a non-interactive shell in any case. Interactive shells may load all sorts of additional plugins that could alter the shell's behaviour unpredictably; that's less likely to happen for a non-interactive shell.
I’m not a shell guru so, for anyone else using fish and having this problem, a workaround is to start VS Code from the shell: code . or code <your project dir>, which then inherits the correct PATH.
When running the test scripts, my output is similar to @sorahn’s above, with PATH being set to /usr/bin:/bin:/usr/sbin:/sbin. All of these paths are controlled by System Integrity Protection so I can’t fix the problem by, say, adding a link to node and npm in /usr/bin.
oh snap. @natesilva that totally worked. Great workaround!
@joaomoreno just checking in, any news on a paths.d fallback or a fish fix?
The latest release has fixed this for me. Thanks!
Fixed for me now... Thanks!
Only running via code . works for me unfortunately - I have no idea why this would be.
@cliffrowley this is because each process inherits the environment (PATH variables and all) from their parent process.
As your shell can parse its own config without any issues it has a full environment it can pass down to any process it starts, like when you do code ., then internally vscode still fails to parse your terminal's config however it already inherited a parsed one from your shell and so all works even though it failed to do its own parsing.
The real problem here is that normally OSX processes are started by launchd (if you run via Finder, dock etc). launchd however doesn't parse your terminal config (it just doesn't know of it) and so does not pass down any of the necessary env variables. So vscode normally has to rely on its own env parsing mechanism and for more exotic shell configurations it breaks as it's basically a hack. That's why we're all here :)
@NinoFloris thanks for the explanation - I was peripherally aware but without the specifics. Is this only a Fish shell issue?
It mostly is, but zsh also had some troubles as did some more exotic bash profiles, although I think all but Fish's problems have been hacked around by now
@NinoFloris ah, brilliant - thanks for the pointers, I shall await a fix patiently and not worry about it affecting multi root support!
@NinoFloris I still can't reproduce this on my machine. I have Fish shell installed and set up as my default shell. And I can't reproduce the issue: I can easily get the environment I configured in ~/.config/fish/config.fish, on my machine. It will be easier if you simply get me the exact version number and let me know whatever customisations you have in Fish.
Nevertheless, I have created #29864 which additionally gets more info from path_helper. Let me know how it goes.
@NinoFloris Let me know when you try this out.
Im having issues with Fish and my PATH as well. It cannot find node nor shfmt when opening projects. In order to suppress these warnings, I must launch VS Code from the CLI.
cc @NinoFloris
hope I can help here, Ive been dealing with this for months on the Insiders builds. thanks!
for me, I feel this is related, since I've never been able to resolve this one without opening from CLI
#24961
this issue is no longer present for me in the latest insiders version!
Interesting. @NinoFloris you too?
I haven't had real issues for a while as tools are including more and more discovery logic to prevent these issues with relying on PATH :)
Alright man, I'll close this then. Sorry we didn't really address it.