On Sun, Oct 17, 2021 at 01:37:34PM +0100, Bram Moolenaar <
Bram@moolenaar.net> wrote:
>
> > On Thu, Oct 14, 2021 at 04:28:14PM +0100, Bram Moolenaar <
Bram@moolenaar.net> 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 -- Bram@Moolenaar.net --
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
vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/YXuzl5uK31sad0qC%40raf.org.
