Zed Terminal opens bash with Raycast, but zsh(default shell) with Spotlight. #8794
Comments
thapabishwa-plerionaut
added
admin read
thapabishwa-plerionaut
changed the title
|
The default shell to open in Zed is set to "system". What happens if you change it to one of your preferred shells? {
"terminal": {
"shell": {
"program": "zsh"
}
}
} |
Moshyfawn
added
terminal
|
Hey @Moshyfawn, my default shell is I see the following with raycast only. Spotlight works fine with the config you suggested.
|
|
Hey there! Few questions to try to nail this down:
|
Works as expected.
Works as expected via CLI too.
Terminal.app iterm2.app |
|
Huh. So what happens when you start Alacritty.app? (That's what we use for the built-in terminal) Do you have any plugins in Raycast that set a |
|
+1 to this issue - when opened via Raycast, Zed says my shell is Not a huge problem since things work as expected when opened with anything that's not Raycast, just wanted to add my experience here. |
|
@aspeth can you try to reproduce what happens when you just launch Alacritty.app, from the Dock and from Raycast? |
|
|
|
This is so weird. I really wonder whether there isn't something going on inside Raycast wrt to env variables. |
|
I'm having a similar issue. Zed is trying to open |
When you open it via Raycast? |
No. When running Zed in general. It is a different case, I don't even have Raycast, but Zed trying to pick a weird shell is similar. I thought I'd mention it just on the off chance it helps with debugging. |
|
@tkgalk can you also try running Alacritty.app? I'm wondering if you have the same problem there. That would help a lot with the debugging. |
|
No, Alacritty seems to respect the default shell. |
|
Found something here: neovide/neovide#2394 Looks like Raycast doesn't forward the |
|
I dug into this a bit, here's what I found:
So, to debug, here's a few things I need. I wrote a little program to reproduce what alacritty does: // main.c
#include <errno.h>
#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
struct Passwd {
const char *name;
const char *dir;
const char *shell;
};
struct Passwd get_pw_entry(char *buf, size_t buflen) {
struct passwd *entry;
struct Passwd result;
memset(&result, 0, sizeof(struct Passwd)); // Zero out the result struct
uid_t uid = getuid();
int status;
struct passwd pw;
status = getpwuid_r(uid, &pw, buf, buflen, &entry);
if (status != 0) {
perror("getpwuid_r failed");
exit(EXIT_FAILURE);
}
if (entry == NULL) {
fprintf(stderr, "pw not found\n");
exit(EXIT_FAILURE);
}
// Sanity check.
if (pw.pw_uid != uid) {
fprintf(stderr, "UID mismatch\n");
exit(EXIT_FAILURE);
}
// Fill the result struct
result.name = pw.pw_name;
result.dir = pw.pw_dir;
result.shell = pw.pw_shell;
return result;
}
int main() {
const size_t buf_size = 1024;
void *buf = malloc(buf_size);
if (buf == NULL) {
fprintf(stderr, "failed to malloc\n");
exit(1);
}
struct Passwd result = get_pw_entry(buf, buf_size);
printf("name: %s\n", result.name);
printf("dir: %s\n", result.dir);
printf("shell: %s\n", result.shell);
return 0;
}You can run it like this: So, for everybody who experiences weird terminal behavior, I need the the following:
|
|
#11751 moved my issue here, as it doesn't seem to be connected to Raycast. My |
|
After fixing my issue with Zed, I installed Raycast just to help, but I can't reproduce the OP's problem. Zed seems to be correctly running the shell from Raycast.
So at least for me seems like Zed is behaving correctly through both Raycast and outside of it. |
|
Another finding that might be related: Alacritty.app doesn't seem to pickup changes made with screenshot-2024-05-13-16.08.59.mp4 |
|
Figured out a little bit more my digging into Alacritty and compiling from source:
That new shell is not picked up, because There's so much environment variables and state involved here, especially when using Raycast/Finder (which are long-running applications) that I think the safest step for further reproduction of bugs is: Make sure you've restarted your computer after making changes to the default shell. |
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.
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](#8794))
…ndustries#11758) This fixes zed-industries#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. ([zed-industries#8794](zed-industries#8794))
Check for existing issues
Describe the bug / provide steps to reproduce it
Zed
settings.jsonVideo:
309617523-78034b9a-25fc-45b5-a60f-69bbc8f224c3.mov
Environment
MacBook Pro
13-inch, M2, 2022
Chip: M2
Memory: 16 GB
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your
~/Library/Logs/Zed/Zed.logfile to this issue.If you only need the most recent lines, you can run the
zed: open logcommand palette action to see the last 1000.No response
The text was updated successfully, but these errors were encountered: