PATH issues with Fish shell on macOS #21655
Comments
|
@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 @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 You can figure this out by running F1, 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: |
|
@jrieken, exactly the same. @joaomoreno sadly no |
|
Is 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 @joaomoreno it returns undefined |
|
running the command directly 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: |
|
Nope from within vscode it returns nothing. running returns the right things! |
|
I can't be much help but I can confirm that using zsh I experience this issue with cargo run. This JSON produces the errror 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 |
|
I use the fish shell and have the exact same problem. The above snippet seems to return correct output: In particular, |
|
Ok took some time to diagnose the issue myself, fish goes belly up when If I just pipe through stderr to inspect it in the process object this is the error shown So the fix is easy, change to 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 |
|
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 |
|
Only running via |
|
@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 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 Nevertheless, I have created #29864 which additionally gets more info from |
|
@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 |
|
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. |
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/bashand 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:
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.path_helperbut also includes all user customizations to PATH from say .bash_profile.path_helperoutput.This way the result will at least always be a working env (for say quite integrated things like spawning a
dotnetprocess 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.
The text was updated successfully, but these errors were encountered: