Closed liujcJone closed 2 years ago
Do you have the "inheritEnv" terminal setting set? What do you get for echo $PATH
?
Fixed here by resetting the default checked "inheritEnv" (I don't remember for which reason I unchecked it). Thanks @roblourens !
I had the same issue. It happened almost the same time as this one. My "inheritEnv" setting was also somehow magically unchecked...
I've had this issue for the last couple days after installing visual studio code onto a new machine.
For some reason, there is no code
binary / executable in my vscode-server
bin directory:
I would like to be able to write code /path/to/file
in an ssh terminal or in the vscode integrated terminal in a remote window in order to open a file/folder in vscode remote.
I am aware that I can use code --folder-uri=vscode-remote://ssh-remote+ADDRESS/path/to/file
from the local machine's terminal, but I want to be able to run a command from within the integrated vscode terminal and any other terminal session where I've ssh'd into the remote machine)
Currently, if I run code
from a remote terminal it opens up a new vscode window on the remote machine.
To achieve this goal, in the past I've used the following alias on the remote machine:
alias code="${VSCODE_GIT_ASKPASS_NODE%/*}/bin/code"
Which looks for the code
executable in ~/.vscode-server/bin/<COMMIT_ID>/bin
before defaulting to the local /bin/code
.
But this doesn't work anymore because there is no code
binary / executable found.
How to fix? I've tried without the alias and nothing works, and inheritEnv is set to true.
I got the same issue. Check on "terminal.integrated.inheritEnv" solves the problem. For the potential reason why it was unchecked. I see the pop-up window from my python env
I have inheritEnv as true , so this is not the problem for me
The "inheritEnv" terminal setting is seted,but it does not work. Dont know why, so I just add code dir do $PATH manually.
This started happening to me today: when using remote-ssh to connect my local VS Code on OS X to a server running Debian linux, VS Code terminals on the remote machine no longer recognize the code command:
$MY_USER@$MY_REMOTE_MACHINE:~$ which code
$MY_USER@$MY_REMOTE_MACHINE:~$ code
bash: code: command not found
$MY_USER@$MY_REMOTE_MACHINE:~$
My $PATH
in the remote terminal contained this folder:
/home/$MY_USER/.vscode-server/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/bin
It looks like that was configured in my ~/.bashrc
, but I have no idea how that got there (I don't remember manually editing that line).
But that folder doesn't exist: a different folder does exist under ~/.vscode-server/bin/
but with a different version hash:
ls -la /home/$MY_USER/.vscode-server/bin/
total 12
drwxr-xr-x 3 $MY_USER $MY_USER 4096 Mar 11 17:28 .
drwxr-xr-x 5 $MY_USER $MY_USER 4096 Mar 11 17:28 ..
drwxr-xr-x 6 $MY_USER $MY_USER 4096 Mar 11 17:28 c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
So it looks like some process previously added an appropriate entry to my $PATH
but that became stale, and nothing repaired it. I tried stopping the remote server VS code instance, uninstalling and reinstalling the remote server VS code instance, and rebooting my remote machine, none of which worked.
This worked for me yesterday.
I noticed that the Remote - SSH extension was updated today (a few hours ago): could this be a regression with the latest release?
This looks highly related: https://github.com/microsoft/vscode-remote-release/issues/6171
And I don't see an option to install the code command on the remote machine.
@tanhakabir it looks like you've commented on several similar issues: does this look like a release-related regression, where the code
command was available on the remote host's path but hard-coded to a specific release, and a new vs code release provides a new bin SHA that breaks PATH lookups, and vscode doesn't repair the path?
I added the workaround in https://github.com/microsoft/vscode-remote-release/issues/6171#issuecomment-1049366932 to my remote ~/.bashrc
with a slight tweak to fix incorrect selection of .
as the latest version (by passing --ignore=.*
to ls
), which unbroke the code
command remotely for me:
code_latest_version=$(ls -tral -1 --ignore=.* ~/.vscode-server/bin | sed -n '2p' | rev | cut -d' ' -f1 | rev)
export PATH=${HOME}/.vscode-server/bin/${code_latest_version}/bin/remote-cli:$PATH
This might have been fixed for users with the terminal inheritEnv setting disabled in the last release: https://github.com/microsoft/vscode-remote-release/issues/6289
We didn't add anything to your bashrc @CodingCanuck. The server tries to add the right folder to your PATH in the environment that terminals are created in. What is your PATH in a remote vscode terminal?
@roblourens without the workaround in https://github.com/microsoft/vscode-remote-release/issues/6339#issuecomment-1065359688, my PATH in a remote vscode terminal doesn't contain any references to vscode.
I'm pretty sure that's because my .bashrc
overwrites PATH, e.g. it has a line like:
# Doesn't read or preserve the current value of $PATH.
export PATH=foo
I sadly have no idea where the contents of my .bashrc
came from: this is a cloud workstation instance that was cloned off of a coworker's instance, and I don't know where that coworker's config came from. But it looks like my .bashrc
is full of widely copy-pasted things, e.g. it's an almost verbatim copy of this one: https://github.com/virtimus/i3c/blob/57ed1f9e4188319f65b71f926e608e3dc29dd00a/dockerfiles/mint/defaults/.bashrc#L119
If I replace all export PATH=foo
lines in my .bashrc
with just this line (with my $USER substituted):
# Preserves the value of $PATH!
export PATH="$PATH:/home/$USER/dev"
then my PATH in a remote vscode terminal looks like (with my $USER substituted):
/home/$USER/.vscode-server/bin/c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1/bin/remote-cli:/home/$USER/.npm-global/bin:/home/$USER/.local/bin:/home/$USER/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/$USER/dev:/home/$USER/dev
Whereas in a non-vscode ssh terminal it looks like:
/home/$USER/.npm-global/bin:/home/$USER/.local/bin:/home/$USER/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/$USER/dev
The double-appending of that /home/$USER/dev
bit that's coming from my altered ~/.bashrc
makes me think that something like this is happening to the PATH:
~/.bashrc
(I'm not sure what process does this)code
binary~/.bashrc
is run sourced a second time: if the ~/.bashrc
contains any destructive PATH sets which don't preserve the value of $PATH then the vscode prepend in step 2 is lostSo the cleaner fix to avoid the workaround in https://github.com/microsoft/vscode-remote-release/issues/6339#issuecomment-1065359688 is to make sure things like ~/.bashrc
always preserve the value of PATH by doing e.g., export PATH=$PATH:foo
rather than export PATH=foo
.
I wonder if it's possible to make vscode more robust to this, though: is it possible to a) avoid the double-sourcing of ~/.bashrc
and/or b) have vscode modify the path after all terminal dotfiles have been sourced?
(I still have no idea how I ended up with my current ~/.bashrc
contents, but that's clearly not a vscode issue!)
I wonder if it's possible to make vscode more robust to this
No, we can't reach inside your terminal process and overwrite the environment that you configured
The double-sourcing we should look into, I am not sure how to avoid it, but should not really cause an issue.
I'd say the issue is having a bashrc that wipes out the inherited PATH, so closing this.
Issue Type: Bug
Update to latest version. Connect to remote-ssh, open terminal, use code command. bash: code: command not found
VS Code version: Code 1.64.2 (f80445acd5a3dadef24aa209168452a3d97cc326, 2022-02-09T22:02:28.252Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No Remote OS version: Linux x64 3.10.0-327.ali2018.alios7.x86_64
System Info
|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (8 x 2112)| |GPU Status|2d_canvas: enabledgpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|7.76GB (1.23GB free)| |Process Argv|--crash-reporter-id fca8bb7c-729f-433e-b0ed-e9f3a31383c2| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|SSH: 11.160.48.83| |OS|Linux x64 3.10.0-327.ali2018.alios7.x86_64| |CPUs|Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz (40 x 2200)| |Memory (System)|64.00GB (61.96GB free)| |VM|0%|
Extensions (19)
Extension|Author (truncated)|Version ---|---|--- Bookmarks|ale|13.2.3 bracket-pair-colorizer-2|Coe|0.2.2 systemd-unit-file|coo|1.0.6 arm|dan|1.7.2 CppSnippets|har|0.0.15 better-cpp-syntax|jef|1.15.13 theme-karyfoundation-themes|kar|25.2.3 l13-diff|L13|1.0.3 kconfig|luv|1.0.3 theme-monokai-pro-vscode|mon|1.1.20 jupyter-keymap|ms-|1.0.0 remote-containers|ms-|0.217.4 remote-ssh|ms-|0.70.0 remote-ssh-edit|ms-|0.70.0 remote-wsl|ms-|0.64.2 vscode-remote-extensionpack|ms-|0.21.0 material-icon-theme|PKi|4.13.0 devicetree|plo|0.1.1 vscode-icons|vsc|11.10.0 (11 theme extensions excluded)A/B Experiments
``` vsliv368:30146709 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythonvspyl392cf:30425750 pythontb:30283811 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 pythondataviewer:30285071 vscod805cf:30301675 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593:30376534 vsc1dst:30433059 pythonvs932:30410667 wslgetstarted:30433507 vsclayoutctrc:30437038 vsrem710cf:30416617 pythonvsnew555cf:30436485 vsbas813:30436447 vscscmwlcmc:30436992 ```