mirror of
https://github.com/zed-industries/zed.git
synced 2024-11-25 00:32:26 +00:00
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
43da37b0ab
This fixes #8794 and other related problems. The problem, in short, is this: `$SHELL` might be outdated. This code ensures that we update `$SHELL` to what we can deem the newest version, if we're started as a desktop application. The background is that you can get the user's preferred shell in two ways: 1. Read the `SHELL` env variable 2. Read the `/etc/passwd` file and check which shell is set Most applications should and do prefer (1) over (2). Why is it preferred? Reading `SHELL` means that processes can inherit the variable from each other. And you can do something like `SHELL=/bin/cool-shell ./my-cool-app` But what happens if the application was launched from the desktop? Which SHELL env does it inherit then? It inherits the env from the process that launched it, which is Finder.app or launchd or GNOME or something else — these are all long-running processes that get their environment when the user logs in. They do *not* get a new environment unless restarted (either process restarted or computer restarted) That means the `SHELL` env variable they have might be outdated. That's a problem if you, for example, change your shell with `chsh` and then launch the app from the desktop. That change of the default shell is not reflected in the app if the app only reads from SHELL. Because that hasn’t been updated. Instead it should read from passwd file to get the newest value. Release Notes: - Fixed SHELL being outdated if Zed was launched via Finder or Raycast or other desktop launchers. ([#8794](https://github.com/zed-industries/zed/issues/8794)) |
||
---|---|---|
.cargo | ||
.config | ||
.github | ||
.zed | ||
assets | ||
crates | ||
docs | ||
extensions | ||
script | ||
tooling/xtask | ||
.dockerignore | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
Cargo.lock | ||
Cargo.toml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
debug.plist | ||
docker-compose.sql | ||
docker-compose.yml | ||
Dockerfile | ||
LICENSE-AGPL | ||
LICENSE-APACHE | ||
LICENSE-GPL | ||
livekit.yaml | ||
Procfile | ||
README.md | ||
rust-toolchain.toml | ||
typos.toml |
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
You can download Zed today for macOS (v10.15+).
Support for additional platforms is on our roadmap:
- Linux (tracking issue)
- Windows (tracking issue)
- Web (tracking issue)
For macOS users, you can also install Zed using Homebrew:
brew install --cask zed
Alternatively, to install the Preview release:
brew install --cask zed@preview
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about
to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specified
error for a crate you've created? If so, addpublish = false
under[package]
in your crate's Cargo.toml. - Is the error
failed to satisfy license requirements
for a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theaccepted
array inscript/licenses/zed-licenses.toml
. - Is
cargo-about
unable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml
, as specified in the cargo-about book.