Re: Weird bug / missing feature with gvim interaction

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Sun, Mar 5, 2023 at 10:28 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Sun, Mar 5, 2023 at 5:34 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > I've been investigating for a while a weird interaction with vim and
> > zsh, and this is the closest I've gotten to narrowing down the
> > problem.
>
> Seems to be a race condition or similar, related to the fact that zsh
> does an "exec" (without forking) of the very last external command
> that it's asked to run, whereas bash and most shells always fork and
> wait.

They wait when they started the child job, when xdg-open spawns a fork
there's nothing to wait for.

> > 2. fork with setsid (the grandchilds are sent SIGHUP)
>
> I believe there is no grandchild, because zsh has replaced itself with
> xdg-open.  If I either run xdg-open under strace -f, or wrap it in
> another script that runs
> /bin/xdg-open "$@"; sleep 1
> then it all works.

Yes, but *only* if you sleep.

> What's not clear is where the HUP is coming from, if you're right
> about that signal.  If this were a tty ownership issue, I'd expect a
> TTIN or TTOU.
>
> Puzzlingly, using "nohup xdg-open ..." doesn't help.

That doesn't help, but "setsid nohup xdg-open ..." does help, both in
bash and zsh. But I believe that's what the vim code essentially tried
to do.

-- 
Felipe Contreras