* Weird bug / missing feature with gvim interaction
@ 2023-03-06 1:32 Felipe Contreras
2023-03-06 4:28 ` Bart Schaefer
2023-03-06 15:14 ` lilydjwg
0 siblings, 2 replies; 8+ messages in thread
From: Felipe Contreras @ 2023-03-06 1:32 UTC (permalink / raw)
To: Zsh hackers list
Hi,
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.
Essentially this doesn't work:
vim -g -c 'set shelltemp' -c ':!xdg-open "https://google.com"'
The reason it doesn't work is that xdg-open immediately spawns a fork,
which is why this doesn't work either:
vim -g -c 'set shelltemp' -c ':!touch /tmp/fork-cur &'
But that actually works in bash.
The two key lines of code from vim are:
setsid();
ioctl(slave, TIOCSCTTY, NULL);
If I remove those, the code works fine, but then it doesn't work with sudo:
vim -g -c 'set shelltemp' -c ':!sudo touch /tmp/sudo &'
But it does with bash.
It is a bit overwhelming, since there are many combinations:
{bash,zsh}{sudo,fork}{sid,}
But long story short, there's a combination that works with bash, but
there isn't a single one that works with zsh.
I wrote a program to be able to test this behavior outside of vim, and
I can reproduce the problem [1].
The two combinations that don't work with zsh are:
1. sudo without setsid (the program cannot feed input into sudo)
2. fork with setsid (the grandchilds are sent SIGHUP)
This is beyond my expertise, but I've tried my best to narrow down the problem.
Is there any way to solve this in zsh?
Cheers.
[1] https://gist.githubusercontent.com/felipec/8a820f3dbf67a5861491553e211400fb/raw/e7f537c0b5b5f4d742f90cfac5f7f046ea61d438/pty-test.c
--
Felipe Contreras
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 1:32 Weird bug / missing feature with gvim interaction Felipe Contreras
@ 2023-03-06 4:28 ` Bart Schaefer
2023-03-06 4:32 ` Bart Schaefer
2023-03-06 14:31 ` Felipe Contreras
2023-03-06 15:14 ` lilydjwg
1 sibling, 2 replies; 8+ messages in thread
From: Bart Schaefer @ 2023-03-06 4:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Zsh hackers list
On Sun, Mar 5, 2023 at 5:34 PM Felipe Contreras
<felipe.contreras@gmail.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
wait.
> 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.
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 4:28 ` Bart Schaefer
@ 2023-03-06 4:32 ` Bart Schaefer
2023-03-06 14:31 ` Felipe Contreras
1 sibling, 0 replies; 8+ messages in thread
From: Bart Schaefer @ 2023-03-06 4:32 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Zsh hackers list
On Sun, Mar 5, 2023 at 8:28 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> another script that runs
> /bin/xdg-open "$@"; sleep 1
> then it all works.
In fact even
vim -g -c 'set shelltemp' -c ':!xdg-open "https://google.com" & sleep 2'
resolves it.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 4:28 ` Bart Schaefer
2023-03-06 4:32 ` Bart Schaefer
@ 2023-03-06 14:31 ` Felipe Contreras
2023-03-06 19:35 ` Bart Schaefer
1 sibling, 1 reply; 8+ messages in thread
From: Felipe Contreras @ 2023-03-06 14:31 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
On Sun, Mar 5, 2023 at 10:28 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sun, Mar 5, 2023 at 5:34 PM Felipe Contreras
> <felipe.contreras@gmail.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
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 1:32 Weird bug / missing feature with gvim interaction Felipe Contreras
2023-03-06 4:28 ` Bart Schaefer
@ 2023-03-06 15:14 ` lilydjwg
2023-03-06 15:54 ` Felipe Contreras
1 sibling, 1 reply; 8+ messages in thread
From: lilydjwg @ 2023-03-06 15:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Zsh hackers list
On Sun, Mar 05, 2023 at 07:32:56PM -0600, Felipe Contreras wrote:
> Hi,
>
> 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.
>
> Essentially this doesn't work:
>
> vim -g -c 'set shelltemp' -c ':!xdg-open "https://google.com"'
What's your Vim version and what `:set go?` reports in your vim? It
seems to be this issue: https://github.com/vim/vim/issues/3327
--
Best regards,
lilydjwg
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 15:14 ` lilydjwg
@ 2023-03-06 15:54 ` Felipe Contreras
0 siblings, 0 replies; 8+ messages in thread
From: Felipe Contreras @ 2023-03-06 15:54 UTC (permalink / raw)
To: lilydjwg; +Cc: Zsh hackers list
On Mon, Mar 6, 2023 at 9:14 AM lilydjwg <lilydjwg@gmail.com> wrote:
>
> On Sun, Mar 05, 2023 at 07:32:56PM -0600, Felipe Contreras wrote:
> > Hi,
> >
> > 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.
> >
> > Essentially this doesn't work:
> >
> > vim -g -c 'set shelltemp' -c ':!xdg-open "https://google.com"'
>
> What's your Vim version and what `:set go?` reports in your vim?
That's not relevant, I can trigger this compiling the latest version
from git and an empty configuration.
It was already discussed in the vim mailing list [1], resulting in a
patch [2], but that patch introduced a problem with sudo.
[1] https://groups.google.com/g/vim_dev/c/gPu_N2LhmK4/m/yAkah4SfBwAJ
[2] https://github.com/vim/vim/commit/6a43b37b760347b9a1bedf12e41b458000922969
--
Felipe Contreras
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 14:31 ` Felipe Contreras
@ 2023-03-06 19:35 ` Bart Schaefer
2023-03-06 19:47 ` Felipe Contreras
0 siblings, 1 reply; 8+ messages in thread
From: Bart Schaefer @ 2023-03-06 19:35 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Zsh hackers list
On Mon, Mar 6, 2023 at 6:31 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> On Sun, Mar 5, 2023 at 10:28 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > What's not clear is where the HUP is coming from
> >
> > 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.
Sure, but vim is doing it before zsh starts up, whereas when you use
the setsid command it creates the new process group after zsh runs it.
E.g., without the setsid command, I believe the thread would be that
zsh execs nohup which execs xdg-open, all with no forking involved,
but if you add setsid in front then zsh execs setsid which forks
before exec of nohup.
Zsh doesn't use setsid(2) and doesn't mess with the process group by
any other means unless there's a controlling tty to attach to, which
there presumably is not in this case.
Still doesn't explain the source of the HUP signal, or why nohup fails
to ignore it ... unless xdg-open is deliberately unblocking it again.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Weird bug / missing feature with gvim interaction
2023-03-06 19:35 ` Bart Schaefer
@ 2023-03-06 19:47 ` Felipe Contreras
0 siblings, 0 replies; 8+ messages in thread
From: Felipe Contreras @ 2023-03-06 19:47 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
On Mon, Mar 6, 2023 at 1:35 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Mon, Mar 6, 2023 at 6:31 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > On Sun, Mar 5, 2023 at 10:28 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> > >
> > > What's not clear is where the HUP is coming from
> > >
> > > 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.
>
> Sure, but vim is doing it before zsh starts up, whereas when you use
> the setsid command it creates the new process group after zsh runs it.
> E.g., without the setsid command, I believe the thread would be that
> zsh execs nohup which execs xdg-open, all with no forking involved,
> but if you add setsid in front then zsh execs setsid which forks
> before exec of nohup.
>
> Zsh doesn't use setsid(2) and doesn't mess with the process group by
> any other means unless there's a controlling tty to attach to, which
> there presumably is not in this case.
>
> Still doesn't explain the source of the HUP signal, or why nohup fails
> to ignore it ... unless xdg-open is deliberately unblocking it again.
I believe that's what happens because GLib's g_spawn_async does
something like that.
When I hunted the code down I believe it does something like this:
#include <spawn.h>
#include <signal.h>
extern char **environ;
int main(void)
{
char *const argv[] = { "/usr/bin/chromium", "http://google.com", NULL };
posix_spawnattr_t attr;
sigset_t mask;
posix_spawnattr_init(&attr);
sigemptyset(&mask);
sigaddset(&mask, SIGHUP);
posix_spawnattr_setsigdefault(&attr, &mask);
posix_spawnattr_setflags(&attr, POSIX_SPAWN_SETSIGDEF);
return posix_spawn(NULL, argv[0], NULL, &attr, argv, environ);
}
--
Felipe Contreras
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-03-06 19:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-06 1:32 Weird bug / missing feature with gvim interaction Felipe Contreras
2023-03-06 4:28 ` Bart Schaefer
2023-03-06 4:32 ` Bart Schaefer
2023-03-06 14:31 ` Felipe Contreras
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
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).