On Monday 13 June 2011, Stefano Lattarini wrote: > On Monday 13 June 2011, Stefano Lattarini wrote: > > Hi Jim. Probably you're totally going to hate me today, but ... > > > > On Monday 13 June 2011, Jim Meyering wrote: > > > > > > From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001 > > > From: Jim Meyering <meyer...@redhat.com> > > > Date: Mon, 13 Jun 2011 18:54:53 +0200 > > > Subject: [PATCH] init.sh: redirect FD 9 to stderr again, for Solaris 10 > > > and HP-UX > > > > > > * tests/init.sh (setup_): When $stderr_fileno_ is not 2, redirect it. > > > Prior to this change, we would redirect before the shell fork-and-exec > > > performed via automake's TESTS_ENVIRONMENT, but that redirection was > > > ineffective on Solaris 10 and HP-UX 11.31, due to the fact that those > > > systems set the CLOEXEC bit on FDs larger than 2. Thus our redirection > > > of FD 9 would not survive the fork-and-exec of running each test script. > > > --- > > > tests/init.sh | 5 +++++ > > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > > > diff --git a/tests/init.sh b/tests/init.sh > > > index 60d1bc1..d101643 100644 > > > --- a/tests/init.sh > > > +++ b/tests/init.sh > > > @@ -317,6 +317,11 @@ path_prepend_ () > > > > > > setup_ () > > > { > > > + # If we're redirecting a file descriptor larger than 2, say via > > > automake's > > > + # TESTS_ENVIRONMENT, that redirected FD is closed-on-exec on some > > > systems > > > + # (at least Solaris 10 and HP-UX 11.x), so redirect it here again. > > > + test $stderr_fileno_ = 2 || eval "exec $stderr_fileno_>&2" > > > + > > > > > ... isn't this equivalent to just using ">&2" unconditionally in 'warn_()'? > > > > IMHO, the right fix is to to modify the code in TESTS_ENVIRONMENT to avoid > > the > > definition of $stderr_fileno_ the shell performs closed-on-exec; e.g., > > > > TESTS_ENVIRONMENT = ...; \ > > if test x"`(exec 9>&1 && sh -c 'echo foo >&9' >/dev/null 2>&1)`" = > > x'foo'; then > > stderr_fileno_=9; export stderr_fileno_; > > else > > unset stderr_fileno_ || : > > fi > > > > If we know that bash and zsh are well behaved, we can even avoid a couple of > > forks (Cygwin users won't hate us too much then): > > > > TESTS_ENVIRONMENT = ...; \ > > if test -n "$${ZSH_VERSION}$${BASH_VERSION}" || \ > > test x"`(exec 9>&1 && sh -c 'echo foo >&9' >/dev/null 2>&1)`" = > > x'foo' > > then > > stderr_fileno_=9; export stderr_fileno_; > > else > > unset stderr_fileno_ || : > > fi > > > > A better fix would be to do the redirect $stderr_fileno_>&2 in tests/init.sh > > iff $stderr_fileno_ is closed, but how can that be portably determined > > without printing trash on the user screen (and for *each* test)? > > > But this last observaton makes me think. The only purpose of $stderr_fileno_ > is to allow the test to print diagnostic on the user's tty, instead of burying > it in the test logs; at this point, we might do the redirection only if the > fd 2 is a tty, so that we will know that, in `tests/init.sh', either: > [1] $stderr_fileno_ refers to a tty, even after the automake parallel-tests > driver has made its own redirections; or: > [2] $stderr_fileno_ is simply the file descriptor 2, which is expected to be > open for writing in any remotely sane setup. > Then we can test, from within tests/init.sh, whether $stderr_fileno_ has been > closed or not by doing: > test 2 -eq "$stderr_fileno_" || test -t "$stderr_fileno_" > and if this is not the case, we eval "exec $stderr_fileno_ >&2" and live > happily. All without extra forks or overly complex `TESTS_ENVIRONMENT' > definitions. > Only that BSD make and Solaris dmake, when running in concurrent mode, redirect stdout/stderr to temporary files or to named or anonymous pipes (for output serialization); so that my proposed idiom wouldn't work with them. Sigh.
Regards, Stefano