> Now, listen. I wish I could continue here and end with “… and this is why ZSH does it that way!”

https://github.com/zsh-users/zsh/blob/47c7bc9b1493c7374f076b... has a comment about this behaviour, but no justification. I think it's just an optimization to save a little bit of time by not forking, and to avoid having the zsh process hanging around taking resources for no reason.

I wonder if restoring the process leader before doing the exec would work out okay, or if that's just going to end up being differently confusing.

I suspect, on the whole, this was a clever idea in theory with unfortunate consequences in practice (much like most of my clever ideas) and would be better just being reverted.

However, I'm not usually a zsh user myself so I'm loath to file a bug given there may be actual zsh users out there who like/rely on this behaviour.

> However, I'm not usually a zsh user myself so I'm loath to file a bug given there may be actual zsh users out there who like/rely on this behaviour.

That sounds like reason for a “won’t fix” response more than a reason not to file the bug in the first place. If nothing else it provides an opportunity to explain why it is the way it is.

> detect when a given language server binary, such as gopls, is already present in $PATH. If so, it should use that instead of downloading a new binary

Please don't do this. If you don't find the file, just bail out. Your editor doesn't have to do everything. Soon enough Zed will be adding an email client

+1 on this. my system already has a package manager. I don't want the same binary installed again in ~/ReinventedWheel24610

Strongly agree here. VS Code extensions with the audacity to download and execute random binaries are particularly pleasant on my NixOS system, where these binaries simply don't work.

I am fine with this behavior as long as I can disable it. Yes, I also use NixOS and don't like when things download random binaries, but I can understand there is demand for things that just work TM.

    // Construct the command we want the $SHELL to execute
    let command = format!("cd {:?}; /usr/bin/env -0;", dir);

SQL Injection-like attacks continues to resurface. You should pass it as a parameter in the future. Untested, but something like this:

    format!("cd \"$1\"; ...");
    command.args([command, dir]);

Rust's debug-print {:?} quotes the path here.

Yes, but rust's quoting does not match shell's quoting. Imagine a path like:

    $(rm -rf /*; echo /)

That's a valid Unix path, but rust's quoting does nothing to stop it: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Wow, so the bottom line is that zsh basically does tail-call elimination with execve on scripts that end with a non-builtin command? That kind of makes sense once you see it, but still, that’s a surprise.

Gosh I am not a fan of long articles that read like a mystery novel.

I am not sure whether I understood it at all but it seems that zsh has a quirk. Interactive shells become the process group leader because they need to manage signals. If you hit Ctrl-C then as a process group leader the signal is forwarded to child processes. And zsh has the quirk that if the last command is not a built-in, zsh calls execve such that zsh becomes the last command. But then the last command is the process group leader and when it exits, no process is the process group leader anymore and Ctrl-C gets lost. Weird.

I am not sure whether this quirk is specific to zsh, but the article mentions zsh, so your mileage might vary.