[xmonad] Why do we close stdin in (some) spawned processes?

[Tomas Janousek]

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: <http://mail.haskell.org/pipermail/xmonad/attachments/20210112/a9b669ff/attachment.html>