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. Vim is not trying to parse the shell command to find the "&", since shell syntax is too complicated, thus we use setsid() always. And if we would not use setsid() then killing Vim would also kill the process that was started from Vim. > > It's difficult to test everything, that is why I prefer to make minimal > > changes that actually solve a problem. > > I agree. For this particular problem the minimal change is enough. > > > If we don't know why that > > setsid() was there, then removing it probably breaks something. > > But I don't agree with this. It's not a good practice to leave code we > don't know what it's doing, and it has been there for 25 years. > > At some point you need to revise code. > > 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. -- John: When I'm playing tennis with friends I always get carried away George: You hurt your foot each time? /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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/202106011342.151DgXii2305128%40masaka.moolenaar.net.
