[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open
Date: Thu, 27 Aug 2020 15:49:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 8/27/20 3:20 PM, Zack Weinberg wrote:
On Thu, Aug 27, 2020 at 2:09 PM Paul Eggert <> 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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]