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

[ivan]

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 <tomi at nomi.cz> 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: <http://mail.haskell.org/pipermail/xmonad/attachments/20210112/dfcdc47c/attachment-0001.html>