From: Felipe Contreras <email@example.com>
To: Bart Schaefer <firstname.lastname@example.org>
Cc: Zsh hackers list <email@example.com>
Subject: Re: Weird bug / missing feature with gvim interaction
Date: Mon, 6 Mar 2023 08:31:14 -0600 [thread overview]
Message-ID: <CAMP44s03ycwi+5e+o5qKrau9neJXdVG9xsyQGMmBaKONuPf6hQ@mail.gmail.com> (raw)
On Sun, Mar 5, 2023 at 10:28 PM Bart Schaefer <firstname.lastname@example.org> wrote:
> On Sun, Mar 5, 2023 at 5:34 PM Felipe Contreras
> <email@example.com> 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
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
next prev parent reply other threads:[~2023-03-06 14:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 1:32 Felipe Contreras
2023-03-06 4:28 ` Bart Schaefer
2023-03-06 4:32 ` Bart Schaefer
2023-03-06 14:31 ` Felipe Contreras [this message]
2023-03-06 19:35 ` Bart Schaefer
2023-03-06 19:47 ` Felipe Contreras
2023-03-06 15:14 ` lilydjwg
2023-03-06 15:54 ` Felipe Contreras
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).