Prepending PATH env var with environmentVariableCollection doesn't work on macOS

[DanTup]

This was covered a little bit in #94153 but that issue is locked and can't be discussed there. This feature feels pretty broken on macOS and I hope might be revisited.

The issue is on macOS prepending to PATH:

context.environmentVariableCollection.prepend("PATH", "/foo/my/path:");

This ends up being added to the end of the path, rather than the start. @Tyriar wrote up why this is in microsoft/vscode-docs@38653d4 and offered two workarounds, however neither of them are usable in my testing (as well as not really being feasible to tell all users to change):

• "terminal.integrated.inheritEnv": false makes no difference at all, the PATH till is added to the end (this is a problem because the purpose of using prepend above is that we need to override any existing SDK on PATH with the one the user just selected)
• "terminal.integrated.shellArgs": [] results in a completely empty PATH besides the values I've prepended, which means that pretty much everything else is missing and won't work. This might be solvable by pushing process.env.PATH into environmentVariableCollection too, however the prompt to the user would look ridiculous as it would include their entire PATH

I appreciate this probably isn't VS Code's fault, but given macOS is fairly common and this behaviour seems to happen on a clean macOS install (it happens on both of mine, and I've customised almost nothing) it feels like it's worth trying to fix (maybe even if it means sending export PATH=foo:$PATH once the shell is initialised? 😄).

[Tyriar]

@DanTup to see whether it's a vscode problem or otherwise you can do a trace log to see what environment the terminal is starting up with https://github.com/microsoft/vscode/wiki/Terminal-Issues#enabling-trace-logging

If the prepend is there, I don't think there's anything we can do?

[DanTup]

@Tyriar I believe the issue is as you describe, which is the default shell startup is building its wn path (with path_helper?) and then pushing that on to the front.

I don't know the solution, but it feels broken enough that it seems worthwhile trying to solve. For example could VS Code pass its own script to the shell to execute that does the prepending? Or could it reliable send an export PATH= command after the terminal initialises? (I don't like that, but if there's no other option and it works reliably, it seems better than this feature being broken on macOS?).

[DanTup]

I had tried with your samples and calling bash -l does break this in a terminal too.

I'm not saying it's VS Code's fault, I just think it's worth VS Code trying to work around in order to have this feature work well. I waited a really long time for this feature, and it sucks that it doesn't seem like I'll be able to use it 😞

[Tyriar]

Yeah this is annoying... I really don't like sending text but it does seem like a workaround is in order. How about the terminal checks on macOS for whether -l or --login is set and then sends export commands as you suggest? Making sure they work on sh, bash, zsh and fish is the bar it would need to meet (mainly just need to verify on fish).

[DanTup]

How about the terminal checks on macOS for whether -l or --login is set

I guess you mean whether it's set in shellArgs (in case the user overrode that from default)? Sounds reasonable to me, though I'm not very familiar with this stuff. If you have a possible fix, I'm definitely happy to test it out on my MacBooks here (with both have this issue) :-)

[Tyriar]

Yes I mean checking the args the terminal is launched with, which will take shellArgs and any explicit args into account if an extension launched it, to be safe it might also be a good idea to make sure the executable is set to something expected too.