Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

[Paul Eggert]

On 8/27/20 3:20 PM, Zack Weinberg wrote:
> On Thu, Aug 27, 2020 at 2:09 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> > > +  if (exec 3>&0) 2>/dev/null; then :; else exec 0</dev/null; fi
> > > +  if (exec 3>&1) 2>/dev/null; then :; else exec 1>/dev/null; fi
> > > +  if (exec 3>&2)            ; then :; else exec 2>/dev/null; fi
> >
> > This is all _AS_ENSURE_STANDARD_FDS needs to do; none of the other stuff is
> > needed and I suggest omitting it as a maintenance time-sink.
>
> I can definitely see how the rest of it could turn into a maintenance
> time sink, but are you sure we don't need a workaround of any kind for
> this construct succeeding even though the target fd is closed, in very
> old shells?

Buggy old shells likely won't benefit from the other stuff anyway, as they'll be 
running in older environments where the other stuff likely doesn't work anyway. 
So the other stuff has little benefit to counterbalance the maintenance timesink.

Another way to put it is that this fault in Autoconf-generated scripts has been 
around for decades and nobody cared because nobody triggered the problem. So the 
only people at all likely to trigger the problem now are people building in 
problematic new stripped-down virtualized platforms the likes of which we didn't 
see in earlier decades. These new platforms will surely not be running ancient 
buggy shells, not only because those buggy shells likely won't work for several 
other reasons, but also because the people building this stuff this new way 
don't care about ancient buggy shells.

> > not that 'read' from 0 or 'write' to 1 or 2 must succeed (there's never any 
> > guarantee of that).
>
> I'm not 100% convinced by this argument but I don't have a real
> counterargument either and in any case it's more on-topic for the
> glibc thread, not here.

True enough.

If it helps, Jim Meyering and I went through this whole discussion years ago in 
coreutils and came up with an approach along the lines that I mentioned. See the 
Gnulib module fdopen, which is used by some GNU programs (though not coreutils 
yet! I should fix that.) Its core implementation is here:

https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/stdopen.c