Linux cannot install gopls when starting zed from .desktop file #21406
Comments
|
Can you let me know which version of Zed you're using? The recent Preview release fixed an issue on Linux where the Could you try latest Preview release? |
This was diagnosed on Discord based on the zed log showing PATH shortly after the gopls errors, and the go directories are present there: |
|
Already wrote: No, did not try the preview. |
jansol
added
language server failure
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Again: Self compiled from git. Pls. read all text from issue!
|
notpeter
added
go
|
Same here, but different setup: Installed via
If P.S. would be nice to be able to copy zed version/commit from |
This is already on the way via #21405 However most of the time the interesting info is in |
|
The same issue happens for me. For now I try to run zed from terminal, but this has other usability problems (since I use tmux, whenever I start terminal inside zed, it would see that tmux env is already set and not start itself.. so either I have tmux or Golang). My version does not log "set environment variables from shell", though, so I have no idea how to give right PATH to Zed. Any workarounds other that starting from terminal? |
… from .desktop file (#22335) Closes #21406 Context: A few weeks ago on Linux, we resolved an [issue](#20070) where users could not open more than one file from the file explorer. This was fixed by replacing `zed-editor` (zed binary in the code) with `zed` (cli binary in the code) in the `.desktop` file. The reason for this change was that using the cli to open files is more convenient - it determines weather to spawn a new Zed instance or use an existing one, if we use main binary instead it would throw error `Zed is already running`. You can read the complete PR here: [linux: Fix file not opening from file explorer](#21137). While this fix resolved the original issue, it introduced a new one. Problem: When the cli binary is used, it assumes it is always being invoked from a terminal and relies on `std::env::vars()` to retrieve the environment variables needed to spawn Zed. These env vars are then passed to the worktree, and eventually, languages use the `PATH` from this env to find binaries. This leads to the "Failed to start language server" error when the `.desktop` entry is used on Linux. Solution: When the `zed-editor` binary is used, it uses some clever Unix-specific logic to retrieve the default shell (`load_shell_from_passwd`) and then fetch the env vars from that shell (`load_login_shell_environment`). This same logic should be used in the cli binary when it is invoked via a `.desktop` entry rather than from a terminal. Approach: I moved these two functions mentioned above to a utils file and reused them in cli binary to fetch env vars only on Linux when it is not run from a terminal. This provides missing paths, and fix the issue. It is also possible to handle this in the `zed-editor` binary by modifying the logic in `handle_cli_connection`, where `CliRequest::Open` is processed. There we can discard incoming env, and use our logic. But discarding incoming envs felt weird, and I thought it's better to handle this at source. Release Notes: - Fixed `Failed to start language server` errors when starting from dekstop entry on Linux
… from .desktop file (zed-industries#22335) Closes zed-industries#21406 Context: A few weeks ago on Linux, we resolved an [issue](zed-industries#20070) where users could not open more than one file from the file explorer. This was fixed by replacing `zed-editor` (zed binary in the code) with `zed` (cli binary in the code) in the `.desktop` file. The reason for this change was that using the cli to open files is more convenient - it determines weather to spawn a new Zed instance or use an existing one, if we use main binary instead it would throw error `Zed is already running`. You can read the complete PR here: [linux: Fix file not opening from file explorer](zed-industries#21137). While this fix resolved the original issue, it introduced a new one. Problem: When the cli binary is used, it assumes it is always being invoked from a terminal and relies on `std::env::vars()` to retrieve the environment variables needed to spawn Zed. These env vars are then passed to the worktree, and eventually, languages use the `PATH` from this env to find binaries. This leads to the "Failed to start language server" error when the `.desktop` entry is used on Linux. Solution: When the `zed-editor` binary is used, it uses some clever Unix-specific logic to retrieve the default shell (`load_shell_from_passwd`) and then fetch the env vars from that shell (`load_login_shell_environment`). This same logic should be used in the cli binary when it is invoked via a `.desktop` entry rather than from a terminal. Approach: I moved these two functions mentioned above to a utils file and reused them in cli binary to fetch env vars only on Linux when it is not run from a terminal. This provides missing paths, and fix the issue. It is also possible to handle this in the `zed-editor` binary by modifying the logic in `handle_cli_connection`, where `CliRequest::Open` is processed. There we can discard incoming env, and use our logic. But discarding incoming envs felt weird, and I thought it's better to handle this at source. Release Notes: - Fixed `Failed to start language server` errors when starting from dekstop entry on Linux
… from .desktop file (zed-industries#22335) Closes zed-industries#21406 Context: A few weeks ago on Linux, we resolved an [issue](zed-industries#20070) where users could not open more than one file from the file explorer. This was fixed by replacing `zed-editor` (zed binary in the code) with `zed` (cli binary in the code) in the `.desktop` file. The reason for this change was that using the cli to open files is more convenient - it determines weather to spawn a new Zed instance or use an existing one, if we use main binary instead it would throw error `Zed is already running`. You can read the complete PR here: [linux: Fix file not opening from file explorer](zed-industries#21137). While this fix resolved the original issue, it introduced a new one. Problem: When the cli binary is used, it assumes it is always being invoked from a terminal and relies on `std::env::vars()` to retrieve the environment variables needed to spawn Zed. These env vars are then passed to the worktree, and eventually, languages use the `PATH` from this env to find binaries. This leads to the "Failed to start language server" error when the `.desktop` entry is used on Linux. Solution: When the `zed-editor` binary is used, it uses some clever Unix-specific logic to retrieve the default shell (`load_shell_from_passwd`) and then fetch the env vars from that shell (`load_login_shell_environment`). This same logic should be used in the cli binary when it is invoked via a `.desktop` entry rather than from a terminal. Approach: I moved these two functions mentioned above to a utils file and reused them in cli binary to fetch env vars only on Linux when it is not run from a terminal. This provides missing paths, and fix the issue. It is also possible to handle this in the `zed-editor` binary by modifying the logic in `handle_cli_connection`, where `CliRequest::Open` is processed. There we can discard incoming env, and use our logic. But discarding incoming envs felt weird, and I thought it's better to handle this at source. Release Notes: - Fixed `Failed to start language server` errors when starting from dekstop entry on Linux
Check for existing issues
Describe the bug / provide steps to reproduce it
See also #18908
When you launch from the desktop file it seems the .profile or .bashrc or whatever is read too late:
If I start from a project directory with
zed .then no error appears.Environment
Linux Ubuntu 24.04
Wayland
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your Zed.log file to this issue.
Zed.log
The text was updated successfully, but these errors were encountered: