Bundled GLib shadowed the system libraries for host plugins dlopen'd
into the process, like PipeWire's videoconvert on 1.6+, which would
break Wayland screen sharing on newer distros. This PR makes Zed rely on
system GLib instead, since the bundled version pulls from whatever is in
CI (presently Ubuntu 20.04).
Release Notes:
- Removed GLib libraries from Linux release bundle, which could conflict
with system plugins
# Objective
Prevent successful installations on 32-bit Linux architectures where the
`zed` binary will **fail to execute** post-installation. Rather, fail at
installation time with a proper verdict.
`script/install.sh` maps `uname -m` onto the two architectures Zed
publishes builds for. Two of the matchers named 32-bit userlands and
mapped them onto a 64-bit tarball:
- `linux-armhf` mapped to `aarch64`
- `linux-i686*` mapped to `x86_64`
Neither can execute the binary it selected. Tested on i386 Debian Trixie
container: the installer downloaded, unpacked, symlinked and reported
success, and the failure surfaced later as an exec error -- see
[Showcase](##showcase).
Thus the installer's correct behavior would be to reject the 32-bit
architecture and terminate with an "unsupported" verdict.
## Solution
Remove the case-statement-based mapping of `linux-armhf` to `aarch64`,
and of `linux-i686*` to `x86_64`.
## Testing
Tested in isolation, simulating supported and unsupported platforms, and
supported and unsupported architectures:
| Platform | `uname -m` | Outcome |
| --- | --- | --- |
| Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created
|
| Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no
case handles plain i386 anyway |
| Linux | `i686` | ❌ Unsupported — same reason |
| Linux | `aarch64` | ✅ Installed — resolves to `aarch64` |
| Linux | `arm64` | ✅ Installed — resolves to `aarch64` |
| Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case |
| Linux | `riscv64` | ❌ Unsupported |
| Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real
`/Applications/Zed.app`, symlink created; |
| Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real
`/Applications/Zed.app`, symlink created |
| Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit |
| FreeBSD | `x86_64` | ❌ Unsupported platform - expected |
This is all correct behavior. Successful installations are expected to
work. Unsupported architectures are detected and rejected as unsupported
during installation.
## Showcase
```plaintext
~# file /usr/bin/dash # a sample executable showing the 32-bit arch
/usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped
~# file .local/zed.app/bin/zed
.local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped
~# .local/zed.app/bin/zed
bash: .local/zed.app/bin/zed: cannot execute: required file not found
# It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is
# a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with:
# `Exec format error`.
```
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Locally conducted tests cover the new/changed behavior
---
Release Notes:
- N/A
Closes#45507
There have been 5+ PRs attempting to fix Linux desktop icon association
by adding `StartupWMClass` back to the `.desktop.in` template (#15763,
#20644, #23459, #33019, #37962), all closed because `StartupWMClass` is
an X11-specific key that GNOME happens to misuse on Wayland, and the
correct fix per the FreeDesktop spec is to name the `.desktop` file to
match the app's Wayland `app_id` / X11 `WM_CLASS`. Refer:
https://github.com/zed-industries/zed/issues/12707#issuecomment-2168742761
The root cause is that `bundle-linux` was never updated to produce the
correct filename in the tarball. The only consumers of the tarball's
desktop file are `install.sh` and manual extractors. So this fix is for
people who download the tarball and extract it without `install.sh`. The
docs already tell them to rename, but as @wcbing points out, not
everyone reads that carefully.
We are now making `bundle-linux` produce the correctly named desktop
file from the start.
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR updates the Linux install script to support installing a
specific version of Zed via the
ZED_VERSION environment variable.
- If ZED_VERSION is set, that version will be downloaded.
- If ZED_VERSION is not set, the script defaults to the latest stable
version, preserving
existing behavior.
- Works for both Linux and macOS installs.
- Maintains compatibility with ZED_CHANNEL for preview builds.
This enhancement allows users to:
- Pin a specific Zed version for reproducible setups or CI workflows.
- Easily install older or known-good versions without manually
downloading release assets.
Usage examples:
- Install latest stable (default):
curl -f https://zed.dev/install.sh | sh
- Install specific version:
curl -f https://zed.dev/install.sh | ZED_VERSION=0.216.0 sh
Use this — it’s correct, concise, and clearly user-facing:
Release Notes
* **Added:** Support for installing a specific Zed version via the
`ZED_VERSION` environment variable in the install script (defaults to
`latest` when unset).
Similar to #42246, we'd like to avoid having Vercel on the critical
path.
https://zed.dev/install.sh is served from Cloudflare by intercepting a
route on that page, so this makes the shell-based install flow vercel independent.
Release Notes:
- `./script/install.sh` will now fetch assets via
`https://cloud.zed.dev/`
instead of `https://zed.dev`. As before it will redirect to GitHub
releases
to complete the download.
## Summary
This PR updates the install script to respect the `TMPDIR` environment
variable when creating temporary directories.
## Motivation
Some environments have non-standard temporary directory locations or
restrictions on `/tmp`. This change allows users to specify an
alternative temporary directory by setting the `TMPDIR` environment
variable.
## Changes
- Check if `TMPDIR` is set and points to a valid directory
- Use `$TMPDIR` for temporary files if available
- Fall back to `/tmp` if `TMPDIR` is not set or invalid
## Testing
Tested the script with:
- `TMPDIR` unset (uses `/tmp` as before)
- `TMPDIR` set to a valid directory (uses specified directory)
- `TMPDIR` set to an invalid path (falls back to `/tmp`)
This change maintains backward compatibility while adding flexibility
for environments with non-standard temporary directory requirements.
Release Notes:
- N/A
Closes#20070
Release Notes:
- Fixed issue where files wouldn't open from the file explorer.
- Fixed "Open a new workspace" option on the desktop entry right-click
menu.
Context:
Zed consists of two binaries:
- `zed` (CLI component, located at `crates/cli/main.rs`)
- `zed-editor` (GUI component, located at `crates/zed/main.rs`)
When `zed` is used in the terminal, it checks if an existing instance is
running. If one is found, it sends data via a socket to open the
specified file. Otherwise, it launches a new instance of `zed-editor`.
For more details, see the `detect` and `boot_background` functions in
`crates/cli/main.rs`.
Root Cause:
Install process creates directories like `.local/zed.app` and
`.local/zed-preview.app`, which contain desktop entries for the
corresponding release. For example, `.local/zed.app/share/applications`
contains `zed.desktop`.
This desktop entry includes a generic `Exec` field, which is correct by
default:
```sh
Comment=A high-performance, multiplayer code editor.
TryExec=zed
StartupNotify=true
```
The issue is in the `install.sh` script. This script copies the above
desktop file to the common directory for desktop entries
(.local/share/applications). During this process, it replaces the
`TryExec` value from `zed` with the exact binary path to avoid relying
on the shell's PATH resolution and to make it explicit.
However, replacement incorrectly uses the path for `zed-editor` instead
of the `zed` CLI binary. This results in not opening a file as if you
use `zed-editor` directly to do this it will throw `zed is already
running` error on production and open new instance on dev.
Note: This PR solves it for new users. For existing users, they will
either have to update `.desktop` file manually, or use `install.sh`
script again. I'm not aware of zed auto-update method, if it runs
`install.sh` under the hood.
This PR fixes some spots in the docs and the `install.sh` script that
were using a mix of tabs and spaces.
We should just be using spaces.
Release Notes:
- N/A
This was broken by two things:
1. A merge conflict in the install.sh script leading to bad sh syntax
2. A return removed by accident when we refactored main
Release Notes:
- N/A
Fixes#12585
This changes the expectations for installed binaries on linux based on
work
that @jirutka has done for Alpine.
In particular, we now put the cli in place as `bin/zed` and the zed
binary as
`libexec/zed-editor`, and assume that packagers do the same.
cc @someone13574
Release notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
- [x] Build out cli on linux
- [x] Add support for --dev-server-token sent by the CLI
- [x] Package cli into the .tar.gz
- [x] Link the cli to ~/.local/bin in install.sh
Release Notes:
- linux: Add cli support for managing zed
This undoes the changes from #11333 and uses the path of the `.desktop`
file instead.
According ot the spec
(https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html)
the filename and path of the `desktop` file are used to determine the
desktop file ID.
This is enough to match the windows (which have the same WMClass/app-id)
with the desktop entry.
Release Notes:
- N/A
