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.