On Tue, Jun 1, 2021 at 8:42 AM Bram Moolenaar <[email protected]> wrote:
>
>
> Felipe Contreras wrote:
>
> > > > > > > > Processes are not being started correctly with TIOCSCTTY, which
> > > > > > > > does
> > > > > > > > succeed after setsid().
> > > > > > > >
> > > > > > > > None of that stuff is necessary, including the silencing of
> > > > > > > > SIGHUP.
> > > > > > > >
> > > > > > > > It's not even executed when shellpipe is off.
> > > > > > >
> > > > > > > I suspect removing setsid() will cause trouble if a terminal with
> > > > > > > a
> > > > > > > shell is started and that shell exits.
> > > > > >
> > > > > > No, I tested that.
> > > > >
> > > > > On which systems?
> > > >
> > > > Linux (5.12.8).
> > >
> > > There are a dozen different Unix-like systems with slightly different
> > > behavior. I care about all of them. It should be possible to at least
> > > test some BSD versions. But there are also SYSV derivatives that
> > > matter, such as HPUX.
> >
> > Yes, but they all try to follow POSIX, and what setsid is supposed to
> > do is defined:
> >
> > https://pubs.opengroup.org/onlinepubs/009604599/functions/setsid.html
> >
> > setsid isn't going to create a new session on Linux, and kill your cat
> > on HPUX.
> >
> > It's supposed to be used when you want to start a daemon that is
> > detached from the parent process, and the terminal.
> >
> > https://unix.stackexchange.com/questions/240646/why-we-use-setsid-while-daemonizing-a-process
> >
> > :! should not start a daemon (especially depending on gui_running and
> > shelltmp).
>
> It can start a background process:
>
> :!startMyServer&
>
> That's what it is for.
This doesn't start a background process:
:!sleep 60
> Vim is not trying to parse the shell command to
> find the "&", since shell syntax is too complicated,
Vim shouldn't parse anything.
If the user wants a background process, he can type the command to
start a background process. If he doesn't, he doesn't.
> thus we use setsid() always.
But we don't use setsid() always.
This doesn't use setsid():
vim -c ':!sleep 60&'
Neither does this:
vim -g -c 'set noshelltemp' -c ':!sleep 60&'
Neither does this:
vim -g -c ':call system("sleep 60&")'
This doesn't work (apparently because of TIOCSCTTY):
vim -g -c 'set shelltemp' -c ':!sleep 60&'
And only *this* sets the setsid:
vim -g -c 'set shelltemp' -c ':!sleep 60'
If setsid was really needed all the commands above would have a
problem, but they don't.
> And if we would not use setsid() then killing Vim
> would also kill the process that was started from Vim.
No it wouldn't. Killing a parent doesn't kill the children.
Try running this program and then kill it.
#include <unistd.h>
int main(void)
{
char *const argv[] = { "/usr/bin/sleep", "60", NULL };
if (fork() == 0)
return execvp(argv[0], argv);
else
return pause();
}
The sleep process will remain there.
> > I can do an investigation of what's going on and why it might have
> > been desirable in 1996 to do setsid(). But to blankly state that it
> > probably breaks something is an assumption. We don't know that. It's
> > possible it simply was copied from somewhere because somebody else did
> > it for some reason.
> >
> > Either way that's a separate topic.
>
> Ideally everything is perfectly documented, commented, tested, etc.
> The reality is that we often don't have the time, and we just fix a
> problem and move on. Otherwise we would have perfectly written code
> with only 10% of the features we have now.
Code that doesn't get cleaned up eventually gets rewritten.
Everything needs to get cleaned up eventually.
Cheers.
--
Felipe Contreras
--
--
You received this message from the "vim_dev" 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_dev" 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_dev/CAMP44s1gQH3r5Wj0UuLEe7s%2B%2BAXu0g%2BAL-xWoG04MKHNMpajxw%40mail.gmail.com.
