On Sun, Oct 17, 2021 at 01:37:34PM +0100, Bram Moolenaar <[email protected]> wrote:
> > > On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar > > <[email protected]> wrote: > > > > > > > Since more than one person complained about this, and it still doesn't > > > > > fully work with zsh, I'll revert 8.2.2919. For zsh we need to find a > > > > > different solution. > > > > > > > > Thanks. Maybe blocking SIGHUP would fix the original problem with > > > > background processes? > > > > > > Hopefully someone can find out what the actualy problem is and find a > > > solution that works and does not cause new problems. > > > > Hmm, SIGHUP is already ignored in the gui. > > Thanks for taking time to look into this. > > > My guess is that the original problem is that most > > shells inherit gvim's ignoring of SIGHUP, but zsh > > doesn't. So the command being executed doesn't ignore > > SIGHUP either, and it dies when zsh terminates, rather > > than when it's finished. But that is just a guess. > > > > It's strange. The original bug report was for Arch Linux. > > But it works fine on Debian Linux. It doesn't work on macOS. > > Thus we don't fully understand the cause of the problem. Perhaps it's a > specific zsh version or how it was configured? I thought that too, i.e., maybe macOS (via macports) and arch have a recent zsh that no longer works, but debian stable might have an older version which still works. But macports and debian stable both have zsh-5.8 which is the latest version. Arch should have the same. Hmm, the system /bin/zsh on my macOS is zsh-5.3 and that works fine. So it's still a mystery. > > I tried the following things on macOS: > > > > - Append "; wait" to the command > > - Prepend "setopt NO_HUP; " to the command > > - Prepend "trap '' HUP; " to the command > > - Prepend "setopt NO_HUP; trap '' HUP; " to the command > > - set shellcmdflag=-o\ nohup\ -c > > > > The only thing that "fixed" it was appending "; wait" > > to the command. Below is a patch that does that, > > only when the gui is running and the shell is zsh and > > there's an ampersand in the command (so "&&" will be a > > false positive). > > > > [...] > > > > But it's awful and hacky. It "fixes" the problem by > > effectively disabling the ability to background a > > process in zsh. And since it isn't a problem on Debian > > Linux, it would make things slightly worse on some > > systems, but only for commands that actually take a > > long time to execute. > > > > Unfortunately, dtruss on macOS isn't working well > > enough for me to trace what's happening. Perhaps > > someone with Arch Linux can use strace to investigate. > > > > Until then, the most practical solution is to just: > > > > set shell=/bin/bash > > > > That fixes it on macOS. > > Well, more a workaround than a fix. But indeed, just setting 'shell' to > something else than zsh should be a workable solution for most users. > > I rather recommend using another shell than to include a hacky solution > with side effects. Indeed. > -- > If Microsoft would build a car... > ... Occasionally your car would die on the freeway for no > reason. You would have to pull over to the side of the road, > close all of the car windows, shut it off, restart it, and > reopen the windows before you could continue. For some reason > you would simply accept this. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// cheers, raf -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YXuzl5uK31sad0qC%40raf.org.
