Re: [PATCH v2] Ensure standard file descriptors are open on start

[Zack Weinberg <zackw@panix.com>]

On Thu, Aug 20, 2020 at 6:00 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Arsen Arsenović wrote:
>  > And considering the hint, and that the edge case of stdin being closed
>  > seems to have been missed even by the autotools developers (I noticed this
>  > when running autoconf-1.64s ./configure from an automation tool that closed
>  > fd 0)
>
> If Autoconf doesn't operate well when file descriptor 0 is closed then it
> might be worth changing Autoconf, if it's not too much trouble.

I looked into making that change.  However, it is very difficult to
detect and handle closed fds 0,1,2 reliably in a shell script.  In C
it's easy (just call fcntl([012], F_GETFL, 0)) but shell programs
cannot make that system call directly, and all of the alternatives
have significant limitations (e.g. not being able to tell whether a fd
is open for *writing*), run foul of bugs (e.g. `exec 3>&0` will
succeed with Solaris /bin/sh, regardless of whether fd 0 was open), or
are not portable enough to use as the sole method (e.g. Linux's
/proc/<pid>/fdinfo/<fd> virtual files).  If you're curious what I did,
see https://lists.gnu.org/archive/html/autoconf-patches/2020-08/msg00025.html
and msg00026.html, but right now I am inclined *not* to put those
changes into the upcoming Autoconf 2.70.

After the experience of writing those patches, I'm definitely in favor
of GNU libc making a guarantee that fds 0,1,2 are open when
application code starts executing, for all processes, regardless of
what POSIX does or does not say.

zw