From tomi at nomi.cz Sat Jan 9 00:41:44 2021 From: tomi at nomi.cz (Tomas Janousek) Date: Sat, 9 Jan 2021 00:41:44 +0000 Subject: [xmonad] using cmark instead of Pandoc in GenerateManPages.hs In-Reply-To: <87lfjkt5n3.fsf@tullinup.koldfront.dk> References: <878sfm9v9r.fsf@tullinup.koldfront.dk> <87r1te8ems.fsf@tullinup.koldfront.dk> <87lfjkt5n3.fsf@tullinup.koldfront.dk> Message-ID: Hi, On Thu, Jul 16, 2020 at 07:01:36AM +0200, Adam Sjøgren wrote: >Adam writes: > >> One of the Debian developers maintaining the Pandoc package remarked: >> >> > I no longer use xmonad myself, but remember frm when I did that the >> > biggest frustration was that you'd need a working _development_ >> > environment, and each time Haskell packages went out of sync (using >> > Debian unstable), xmonad was one of the last ones to get back in >> > sync. I imagine that a decoupling from Pandoc might change that. > >[...] > >> I will be happy to take a stab at changing GenerateManPage to use cmark >> instead of Pandoc, if it sounds useful to you. > >I have tried doing so now - Pandoc does more than cmark, so it's more >intrusive than I would have liked. >[...] I tried an alternative approach: drop the Haskell dependency on Pandoc/cmark entirely and use the command-line interface, which I believe is more stable than the Haskell library interface. I implemented that here: https://github.com/xmonad/xmonad/pull/260 Do you folks think this is a viable option or are there any pitfalls that I'm not seeing? Any feedback highly appreciated. -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.brennan at gmail.com Tue Jan 12 15:06:06 2021 From: ivan.brennan at gmail.com (ivan) Date: Tue, 12 Jan 2021 10:06:06 -0500 Subject: [xmonad] Why do we close stdin in (some) spawned processes? Message-ID: In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' from xmonad-contrib we do not. I'm curious why that's the case? This commit introduced the code that closes stdin, but doesn't describe the motivation for doing so: https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3 I suspect we close stdin in 'spawn' because we know it won't be needed, but I'm still not sure what we gain by closing it (does it improve efficiency?). And should we be closing it in 'safeSpawn' as well, or does 'safeSpawn' have a use-case that requires reading from stdin? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Jan 12 15:13:33 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 12 Jan 2021 10:13:33 -0500 Subject: [xmonad] Why do we close stdin in (some) spawned processes? In-Reply-To: References: Message-ID: Probably we should not be closing it; or at least should have it open on /dev/null. There is a general expectation in the POSIX model that fds 0, 1, 2 are open. On Tue, Jan 12, 2021, 10:06 ivan wrote: > In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' > from xmonad-contrib we do not. I'm curious why that's the case? > > This commit introduced the code that closes stdin, but doesn't describe > the motivation for doing so: > > https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3 > > I suspect we close stdin in 'spawn' because we know it won't be needed, > but I'm still not sure what we gain by closing it (does it improve > efficiency?). And should we be closing it in 'safeSpawn' as well, or does > 'safeSpawn' have a use-case that requires reading from stdin? > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomi at nomi.cz Tue Jan 12 20:46:42 2021 From: tomi at nomi.cz (Tomas Janousek) Date: Tue, 12 Jan 2021 20:46:42 +0000 Subject: [xmonad] Why do we close stdin in (some) spawned processes? In-Reply-To: References: Message-ID: Hi Ivan, On Tue, Jan 12, 2021 at 10:06:06AM -0500, ivan wrote: >In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' >from xmonad-contrib we do not. I'm curious why that's the case? > >This commit introduced the code that closes stdin, but doesn't describe the >motivation for doing so: >https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3 When you log in on a vt and do "startx $(which xmonad)", xmonad runs with fds 0, 1 and 2 connected to /dev/ttyN. If it didn't close (actually redirect from /dev/null) stdin, some programs might think they're being run from the terminal, I guess, and/or perhaps get stuck reading from it. This is obviously a rather non-standard way of launching xmonad, so probably irrelevant, but: The less unusual "startx" without arguments (having xmonad in .xinitrc or .xsession), /etc/X11/xinit/xinitrc invokes /etc/X11/Xsession which redirects stdout and stderr to .xsession-errors (this may be distro-specific, I'm on Debian), but it does not touch stdin, so that issue probably remains. I can't think of a specific app that breaks, off the top of my mind, but I'd be surprised if there weren't any. >And should we be closing it in 'safeSpawn' as well, or does >'safeSpawn' have a use-case that requires reading from stdin? I can't think of any such use-case. Using 'xfork' in 'safeSpawn' should be just fine. -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.brennan at gmail.com Tue Jan 12 22:06:25 2021 From: ivan.brennan at gmail.com (ivan) Date: Tue, 12 Jan 2021 17:06:25 -0500 Subject: [xmonad] Why do we close stdin in (some) spawned processes? In-Reply-To: References: Message-ID: Actually, I misspoke (and so did the commit message) -- we aren't closing stdin, but rather redirecting it to /dev/null. On Tue, Jan 12, 2021 at 10:13 AM Brandon Allbery wrote: > Probably we should not be closing it; or at least should have it open on > /dev/null. There is a general expectation in the POSIX model that fds 0, 1, > 2 are open. > > On Tue, Jan 12, 2021, 10:06 ivan wrote: > >> In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' >> from xmonad-contrib we do not. I'm curious why that's the case? >> >> This commit introduced the code that closes stdin, but doesn't describe >> the motivation for doing so: >> >> https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3 >> >> I suspect we close stdin in 'spawn' because we know it won't be needed, >> but I'm still not sure what we gain by closing it (does it improve >> efficiency?). And should we be closing it in 'safeSpawn' as well, or does >> 'safeSpawn' have a use-case that requires reading from stdin? >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.brennan at gmail.com Tue Jan 12 22:29:15 2021 From: ivan.brennan at gmail.com (ivan) Date: Tue, 12 Jan 2021 17:29:15 -0500 Subject: [xmonad] Why do we close stdin in (some) spawned processes? In-Reply-To: References: Message-ID: Thanks for the explanation, that makes sense. I looked at the history of 'safeSpawn' and interestingly, it used to call xfork, but that was changed in this commit: https://github.com/xmonad/xmonad-contrib/commit/1844c80978844611f7d409cab7c313bb0c0649bf The issue described in that commit, though, seems to be related to signal handlers rather than stdin (though it also sounds like the exact issue may not have been identified). On Tue, Jan 12, 2021 at 3:46 PM Tomas Janousek wrote: > Hi Ivan, > > On Tue, Jan 12, 2021 at 10:06:06AM -0500, ivan wrote: > > In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' > from xmonad-contrib we do not. I'm curious why that's the case? > > This commit introduced the code that closes stdin, but doesn't describe the > {.quotelead}>motivation for doing so: > > > https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3 > > When you log in on a vt and do "startx $(which xmonad)", xmonad runs with > fds 0, 1 and 2 connected to /dev/ttyN. If it didn't close (actually > redirect from /dev/null) stdin, some programs might think they're being run > from the terminal, I guess, and/or perhaps get stuck reading from it. > > This is obviously a rather non-standard way of launching xmonad, so > probably irrelevant, but: > > The less unusual "startx" without arguments (having xmonad in .xinitrc or > .xsession), /etc/X11/xinit/xinitrc invokes /etc/X11/Xsession which > redirects stdout and stderr to .xsession-errors (this may be > distro-specific, I'm on Debian), but it does not touch stdin, so that issue > probably remains. I can't think of a specific app that breaks, off the top > of my mind, but I'd be surprised if there weren't any. > > And should we be closing it in 'safeSpawn' as well, or does > 'safeSpawn' have a use-case that requires reading from stdin? > > I can't think of any such use-case. Using 'xfork' in 'safeSpawn' should be > just fine. > -- > Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomi at nomi.cz Tue Jan 12 22:51:19 2021 From: tomi at nomi.cz (Tomas Janousek) Date: Tue, 12 Jan 2021 22:51:19 +0000 Subject: [xmonad] Why do we close stdin in (some) spawned processes? In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 05:29:15PM -0500, ivan wrote: >Thanks for the explanation, that makes sense. I looked at the history of >'safeSpawn' and interestingly, it used to call xfork, but that was changed >in this commit: >https://github.com/xmonad/xmonad-contrib/commit/1844c80978844611f7d409cab7c313bb0c0649bf That commit makes no sense. xfork always did uninstallSignalHandlers. Actually, xfork is still exactly the same function it was in 2009 when it appeared for the first time. The only exaplanation I have is that the reporter of https://code.google.com/archive/p/xmonad/issues/441 used xmonad-contrib that didn't use xfork yet (that is, before https://github.com/xmonad/xmonad-contrib/commit/e8c0f39fd5238771d14b920b8b87f89e7b56c30f), and reported an issue which gwern tried to fix without knowing it'd already been fixed but the reporter isn't running the fix yet, and pushed yet another fix (1844c8097 that you mentioned) but forgot about stdin. This explanation assumes the problem was in signal handling, but the discussion in https://code.google.com/archive/p/xmonad/issues/441 looks like it was, indeed. So I think 1844c8097 can just be reverted, the issue was most probably already fixed by e8c0f39fd5. >The issue described in that commit, though, seems to be related to signal >handlers rather than stdin (though it also sounds like the exact issue may >not have been identified). -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/ -------------- next part -------------- An HTML attachment was scrubbed... URL: