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/353e7cd6811245fbee7c8c6cf821041c9245...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

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/1844c80978844611f7d409cab7c3... 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/353e7cd6811245fbee7c8c6cf821041c9245...

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/