Closes#39614
The `ShellKind` struct is built on Windows' side, meaning that when
connecting to remotes, we fall back to PowerShell construction, even if
the shell program we are spawning is a unix program.
This broke tasks creation since we are using the shell kind to construct
args:
https://github.com/zed-industries/zed/blob/d04ac864b8cb78ee888ce03323e34c17a6dd16b9/crates/project/src/terminals.rs#L149
In normal terminals this only affected activation scripts (only place
where shell kind is used)
I don't have a Windows machine to test it, so I would appreciate any
help with testing!
Release Notes:
- Fixed an issue where tasks could not be executed in Windows WSL
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
When sourcing the project environment for the terminal tool, we will now
do so by spawning the shell specified by the users `terminal.shell`
setting (or as usual fall back to the login shell).
Closes#37687
Release Notes:
- N/A
Using `crate::command::new_smol_command` on the Windows platform will
not display the PowerShell window.
Closes#39052
Release Notes:
- N/A
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Fixes the "failed to get working directory environment for repository"
error on Windows by implementing proper shell environment variable
capture.
Release Notes:
- Fixed failed to get working directory environment for repository
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Follow-up to: https://github.com/zed-industries/zed/pull/32637
When Zed is installed in a path containing spaces (e.g.,
`/Applications/Zed Nightly.app/Contents/MacOS/zed`), environment
variable loading fails and leaves this in the Zed log:
```
login shell exited with exit status: 127. stdout: "", stderr: "Nightly.app/Contents/MacOS/zed --printenv >&0: /Applications/Zed: No such file or directory"
```
This was not part a release (only broke in nightly), but fixes it the
issue in any case when the path to the Zed.app bundle has a space (e.g.
"Zed Nightly.app")
Release Notes:
- N/A
Fixes#11647Fixes#13888Fixes#18771Fixes#19779Fixes#22437Fixes#23649Fixes#24200Fixes#27601
Zed’s current method of loading environment variables from the login
shell has two issues:
1. Some shells—fish in particular—write specific escape characters to
`stdout` right before they exit. When this happens, the tail end of the
last environment variable printed by `/usr/bin/env` becomes corrupted.
2. If a multi-line value contains an equals sign, that line is
mis-parsed as a separate name-value pair.
This PR addresses those problems by:
1. Redirecting the shell command's `stdout` directly to a temporary
file, eliminating any side effects caused by the shell itself.
2. Replacing `/usr/bin/env` with `sh -c 'export -p'`, which removes
ambiguity when handling multi-line values.
Additional changes:
- Correctly set the arguments used to launch a login shell under `csh`
or `tcsh`.
- Deduplicate code by sharing the implementation that loads environment
variables on first run with the logic that reloads them for a project.
Release Notes:
- N/A
Marco Mihai Condrache
Merlin04andJakub Konka
Lukas Wirth
Xiaobo Liu
Todd L Smith
Peter Tripp
Kyle Kelley
Stanislav Alekseev
Haru Kim