2021-10-04 19:07:35 +00:00
|
|
|
[package]
|
|
|
|
|
name = "util"
|
|
|
|
|
version = "0.1.0"
|
2022-01-26 20:50:31 +00:00
|
|
|
edition = "2021"
|
2023-01-18 20:28:02 +00:00
|
|
|
publish = false
|
2024-01-23 15:56:22 +00:00
|
|
|
license = "Apache-2.0"
|
2024-01-23 16:40:30 +00:00
|
|
|
|
2024-03-05 17:01:17 +00:00
|
|
|
[lints]
|
|
|
|
|
workspace = true
|
|
|
|
|
|
2022-03-04 00:15:56 +00:00
|
|
|
[lib]
|
2023-02-18 01:19:23 +00:00
|
|
|
path = "src/util.rs"
|
2023-03-29 14:31:55 +00:00
|
|
|
doctest = true
|
2022-03-04 00:15:56 +00:00
|
|
|
|
2021-10-04 19:07:35 +00:00
|
|
|
[features]
|
2024-08-28 08:05:50 +00:00
|
|
|
test-support = ["tempfile", "git2", "rand"]
|
2021-10-04 19:07:35 +00:00
|
|
|
|
|
|
|
|
[dependencies]
|
2023-04-25 00:41:55 +00:00
|
|
|
anyhow.workspace = true
|
2024-10-02 14:38:23 +00:00
|
|
|
async-fs.workspace = true
|
2024-02-07 17:06:03 +00:00
|
|
|
collections.workspace = true
|
2024-06-17 23:27:42 +00:00
|
|
|
dirs.workspace = true
|
2024-10-02 14:38:23 +00:00
|
|
|
futures-lite.workspace = true
|
2023-04-25 00:41:55 +00:00
|
|
|
futures.workspace = true
|
2024-01-31 02:41:29 +00:00
|
|
|
git2 = { workspace = true, optional = true }
|
|
|
|
|
globset.workspace = true
|
2024-12-20 22:16:07 +00:00
|
|
|
itertools.workspace = true
|
2024-01-31 02:41:29 +00:00
|
|
|
log.workspace = true
|
2024-10-02 14:38:23 +00:00
|
|
|
rand = { workspace = true, optional = true }
|
2024-03-11 15:08:18 +00:00
|
|
|
regex.workspace = true
|
2023-06-06 18:46:46 +00:00
|
|
|
rust-embed.workspace = true
|
2023-04-25 00:41:55 +00:00
|
|
|
serde.workspace = true
|
|
|
|
|
serde_json.workspace = true
|
2024-11-21 00:52:38 +00:00
|
|
|
smol.workspace = true
|
2023-05-11 19:01:42 +00:00
|
|
|
take-until = "0.2.0"
|
2024-01-31 02:41:29 +00:00
|
|
|
tempfile = { workspace = true, optional = true }
|
2024-02-28 09:03:34 +00:00
|
|
|
unicase.workspace = true
|
2022-09-26 14:59:51 +00:00
|
|
|
|
linux: Fix "Failed to start language server" errors when starting Zed from .desktop file (#22335)
Closes #21406
Context:
A few weeks ago on Linux, we resolved an
[issue](https://github.com/zed-industries/zed/issues/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](https://github.com/zed-industries/zed/pull/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
2024-12-22 10:05:52 +00:00
|
|
|
[target.'cfg(unix)'.dependencies]
|
|
|
|
|
libc.workspace = true
|
|
|
|
|
|
2024-01-30 18:07:46 +00:00
|
|
|
[target.'cfg(windows)'.dependencies]
|
|
|
|
|
tendril = "0.4.3"
|
Better absolute path handling (#19727)
Closes #19866
This PR supersedes #19228, as #19228 encountered too many merge
conflicts.
After some exploration, I found that for paths with the `\\?\` prefix,
we can safely remove it and consistently use the clean paths in all
cases. Previously, in #19228, I thought we would still need the `\\?\`
prefix for IO operations to handle long paths better. However, this
turns out to be unnecessary because Rust automatically manages this for
us when calling IO-related APIs. For details, refer to Rust's internal
function
[`get_long_path`](https://github.com/rust-lang/rust/blob/017ae1b21f7be6dcdcfc95631e54bde806653a8a/library/std/src/sys/path/windows.rs#L225-L233).
Therefore, we can always store and use paths without the `\\?\` prefix.
This PR introduces a `SanitizedPath` structure, which represents a path
stripped of the `\\?\` prefix. To prevent untrimmed paths from being
mistakenly passed into `Worktree`, the type of `Worktree`’s `abs_path`
member variable has been changed to `SanitizedPath`.
Additionally, this PR reverts the changes of #15856 and #18726. After
testing, it appears that the issues those PRs addressed can be resolved
by this PR.
### Existing Issue
To keep the scope of modifications manageable, `Worktree::abs_path` has
retained its current signature as `fn abs_path(&self) -> Arc<Path>`,
rather than returning a `SanitizedPath`. Updating the method to return
`SanitizedPath`—which may better resolve path inconsistencies—would
likely introduce extensive changes similar to those in #19228.
Currently, the limitation is as follows:
```rust
let abs_path: &Arc<Path> = snapshot.abs_path();
let some_non_trimmed_path = Path::new("\\\\?\\C:\\Users\\user\\Desktop\\project");
// The caller performs some actions here:
some_non_trimmed_path.strip_prefix(abs_path); // This fails
some_non_trimmed_path.starts_with(abs_path); // This fails too
```
The final two lines will fail because `snapshot.abs_path()` returns a
clean path without the `\\?\` prefix. I have identified two relevant
instances that may face this issue:
-
[lsp_store.rs#L3578](https://github.com/zed-industries/zed/blob/0173479d18e2526c1f9c8b25ac94ec66b992a2b2/crates/project/src/lsp_store.rs#L3578)
-
[worktree.rs#L4338](https://github.com/zed-industries/zed/blob/0173479d18e2526c1f9c8b25ac94ec66b992a2b2/crates/worktree/src/worktree.rs#L4338)
Switching `Worktree::abs_path` to return `SanitizedPath` would resolve
these issues but would also lead to many code changes.
Any suggestions or feedback on this approach are very welcome.
cc @SomeoneToIgnore
Release Notes:
- N/A
2024-11-27 18:22:58 +00:00
|
|
|
dunce = "1.0"
|
2024-01-30 18:07:46 +00:00
|
|
|
|
2022-08-03 21:20:05 +00:00
|
|
|
[dev-dependencies]
|
2023-09-19 20:13:47 +00:00
|
|
|
git2.workspace = true
|
2024-08-28 08:05:50 +00:00
|
|
|
rand.workspace = true
|
2024-10-02 14:38:23 +00:00
|
|
|
tempfile.workspace = true
|
