[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
From: |
Stefano Lattarini |
Subject: |
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed |
Date: |
Mon, 13 Jun 2011 22:41:04 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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 <address@hidden>
> > 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 tess/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.
WDYT?
Regards,
Stefano
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, (continued)
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Jim Meyering, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Bruno Haible, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Jim Meyering, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Jim Meyering, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Jim Meyering, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Bruno Haible, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Jim Meyering, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed,
Stefano Lattarini <=
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/14
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Eric Blake, 2011/06/13
- bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed, Stefano Lattarini, 2011/06/14