[HN Gopher] How to Lose Control of Your Shell
       ___________________________________________________________________
        
       How to Lose Control of Your Shell
        
       Author : todsacerdoti
       Score  : 70 points
       Date   : 2024-03-09 16:09 UTC (6 hours ago)
        
 (HTM) web link (registerspill.thorstenball.com)
 (TXT) w3m dump (registerspill.thorstenball.com)
        
       | colinng wrote:
       | Gosh I am not a fan of long articles that read like a mystery
       | novel.
        
         | _nalply wrote:
         | 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.
        
       | jamespwilliams wrote:
       | > 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.
        
         | mst wrote:
         | 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.
        
       | 38 wrote:
       | > 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
        
         | vrighter wrote:
         | +1 on this. my system already has a package manager. I don't
         | want the same binary installed again in ~/ReinventedWheel24610
        
         | xcdzvyn wrote:
         | 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.
        
       | wrs wrote:
       | 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.
        
       | hn92726819 wrote:
       | // 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]);
        
       ___________________________________________________________________
       (page generated 2024-03-09 23:01 UTC)