Open cglosser opened 5 years ago
Is ZSH your default shell? There's a chance we resolve the path using /bin/sh
(?) rather than user-default shell, so maybe that's the issue
Yep, ZSH is my default shell. It looks like ZSH, Bash, and /bin/sh
(which aliases Dash) can all source cargo correctly on my machine, though.
I've been getting this quite a lot recently, can't remember exactly what I did to fix it but nothing is working this morning.
If I run sh
myself, I can run the rust commands fine, same from fish, same from bash, same from all shells.
The console outputs:
Starting client failed
Error: Command failed: rustup toolchain list
/bin/sh: rustup: command not found
I've no idea what's going on, I can't use any of the tooling suddenly.
I've already tried:
rustup self uninstall
+ reinstallRan into this too, and highlighting: from macOS Catalina onwards, the default shell is zsh. This has a chance to hit lots of new people.
Rust (rls)
, from the plugins tab of VSCodeCommand failed: rustup toolchain list /bin/sh: rustup: command not found
rustup
installation modified my .profile
, adding the line
export PATH="$HOME/.cargo/bin:$PATH"
and rustup
works in both alacritty and terminal using both zsh or sh.
However, the extension itself cannot seem to resolve where rustup
lives.
Happy to provide more debug information / help with this, just let me know how 🙂
My guess is that interactive shells are reading .profile
but that the shell invoked by VSCode is not.
I ran into this today and want to jot down some info about part of this issue.
My default shell is /bin/zsh
on MacOS 10.14.6, but I also notice that /bin/sh
is being used as the shell to check for the Rustup toolchain. Here are my Rust Language Server Output logs/error messages:
[Error - 12:05:56 AM] Starting client failed
Error: Command failed: rustup toolchain list
/bin/sh: rustup: command not found
at ChildProcess.exithandler (child_process.js:303:12)
at ChildProcess.emit (events.js:200:13)
at maybeClose (internal/child_process.js:1021:16)
at Socket.<anonymous> (internal/child_process.js:430:11)
at Socket.emit (events.js:200:13)
at Pipe.<anonymous> (net.js:586:12)
I found the following function, which checks for Rustup and logs and rethrows this error.
By default, child_process.exec()
(which is being used to call rustup toolchain list
) defaults to the /bin/sh
shell. This can be overridden with an option:
function defaultShell(): string {
// determine default shell
}
const { stdout } = await withWsl(config.useWSL).exec(
`${config.path} toolchain list`,
{ shell: defaultShell() }
);
The implementation of default shell could be from an npm package (like default-shell), or something custom to this project, depending on what's preferred.
I have not tried to fix this locally and test yet, but I wanted to comment with this info before I forget to. 😄
My guess is that interactive shells are reading .profile but that the shell invoked by VSCode is not.
That would also be my guess too, because even if this extension used the default shell when executing these commands but didn't load the proper .profile
, I think we'd still be in the same place overall. I don't know enough about VSCode internals to know if there is an option to read in .profile
or if there is an API they provide that does this? 🤔
I had this exact problem using fish shell. I fixed it by specifying path for rustup in the config.
"rust-client.rustupPath": "~/.cargo/bin/rustup"
Reloaded, and after that I was prompted to install RLS and everything went smoothly.
UPDATE I've just realized that this answer is specified in the original question itself, lol.
Same problem on Mac where zsh is now the default shell.
@drozzy did you ever find a fix for it?
for anyone that just upgraded to catalina and is getting the error run
[[ -e ~/.profile ]] && emulate sh -c 'source ~/.profile'
in your terminal. <-- this will require you to run the above code everytime.
----EDIT---- This fixed it for me for now... open your ~/zprofile. and also open your bash_profile ( thats what i was using) then copy the files from bash profile into z profile and save it.
rust-client.rustupPath
It's works for me, but I was wrong at first. I have not noticed that the setting of WSL and local window is in different JSON file. This setting should paste to the WSL's JSON file. Others who need help should pay attention to this.
export PATH="$HOME/.cargo/bin:$PATH"
add this line in ~/.zshrc
, then restart system(maybe).
Not sure if this is related to issue reported originally, noting here as search for similar OS X Catalina issue brought me to this thread. For OSX Catalina, if after install you see an error like:
zsh _rustup:12: command not found: _arguments
Make sure you read all the install steps for zsh. After checking for export paths and other steps noted, I had overlooked:
For zsh, you must then add the following line in your ~/.zshrc before compinit
fpath+=~/.zfunc
Reading is a super power. Added. Fixed.
Just adding on my experience: I'm using MacOS Catalina and zsh, and like others, I was getting the popups saying
Couldn't start client Rust Language Server Rustup not available. Install from https://www.rustup.rs/
The Rust Language Server output said:
Error: Command failed: rustup toolchain list
/bin/sh: rustup: command not found
In my case, I had just installed rustup and I could successfully run /bin/sh -c rustup
from the terminal, so it seemed like it was just VSCode using an outdated PATH. Fully exiting out of VSCode and starting it again fixed the issue for me- "Reload Window" wasn't enough.
For people who use VSCode Remote, you have to configure rustup path in the Remote profile settings. It works for me.
{
"rust-client.rustupPath": "~/.cargo/bin/rustup",
}
or you can use the rls and rustup from the shell by setting "rust-client.disableRustup": true
in your config
I have this issue today, tried to add "rust-client.rustupPath": "~/.cargo/bin/rustup"
to the remote settings.json
but I have a Unknown Configuration Setting
for this key
@Geobert which Code extension are you using?
@Geobert which Code extension are you using?
rust-analyzer 0.4.1198
You're in the repository of the old extension (RLS), and rust-client.rustupPath
is a setting it used to have. For RA it's usually enough to have it in PATH
.
Oh, I might need to ask on RA's repo then, thanks for your answer! :)
This is almost certainly related to #577 (now closed) but I'm getting
errors on a clean install of Debian + VSCode + Rust. The fix mentioned in #577, setting
explicitly fixes this issue, but VSCode then can't find
cargo
when I run build tasks. I suspect it's not sourcing some path info correctly; is there a way to check this?Version info
Debian
Debian version: 10 (Buster)
VSCode
Version: 1.38.1 Commit: b37e54c98e1a74ba89e03073e5a3761284e3ffb0 Date: 2019-09-11T13:30:08.229Z Electron: 4.2.10 Chrome: 69.0.3497.128 Node.js: 10.11.0 V8: 6.9.427.31-electron.0 OS: Linux x64 4.19.0-6-amd64
Rust/up
Default host: x86_64-unknown-linux-gnu rustup home: /home/connor/.rustup
stable-x86_64-unknown-linux-gnu (default) rustc 1.38.0 (625451e37 2019-09-23)
ZSH
zsh 5.7.1 (x86_64-debian-linux-gnu)