🚀 go-pugleaf

In emacs 18.59, correct behavior of child processes depends on emacs
having file descriptors 1 and 2 open.  Otherwise, child_setup closes
one or more of the file descriptors passed to it.

One consequence is that child processes do not work properly in an
emacs process started as "emacs >&- 2>&-".  A shell buffer, for
example, exits immediately because of its input being closed.  If only
one of the file descriptors is closed, as in "emacs >&-", the shell
doesn't exit, but none of its output is visible.

If emacs is running on an ordinary terminal, it is unreasonable to
expect it to work with file descriptors 1 and 2 closed.  However, if
it is running as an X client, it seems reasonable that it should work
properly even if file descriptors 1 and 2 are closed.  As a point of
comparison, xterm works just fine if file descriptors 0, 1, and 2 are
all closed.  The child code xterm uses to map its tty into the
standard file descriptors looks like this:


		    for (i = 0; i <= 2; i++)
			if (i != tty) {
			    (void) close(i);
			    (void) dup(tty);
			}


I don't have a patch which allows emacs child processes to work when
file descriptors 1 and 2 are closed.  I see a few likely alternatives.


1)  Leave it as is, and don't worry about whether it is reasonable to
run emacs with file descriptors 1 and 2 closed.

2)  In the code that allocates a pty or pipe for a child process, check
whether the file descriptors are bigger than 2; if not, dup them until
they are.

3)  Complicate the code in child_setup to handle file descriptors for
in, out, and err which are less than 3.

4)  In the emacs initialization, open file descriptors 1 and 2 if they
are not already open.  Perhaps they could be opened as /dev/null if
they are not already open, or dup'd to something else.


Of these alternatives, the third and fourth seem the most robust.  The
first one doesn't fix the problem, and the second one probably leaves
some cases unfixed.  The problem, in essence, is that child_setup
assumes its arguments never overlap the standard file descriptors.  It
is both possible and (in my opinion) reasonable to violate this
assumption.

If the fourth alternative is chosen, it might be reasonable to
implement it in x_init_1 (which initializes X keyboard input), since
it only seems reasonable to close file descriptors 1 and 2 when emacs
is running as an X client.