GNU bug report logs - #8846
coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed

Previous Next

Full log

Message #92 received at 8846 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8846 <at> debbugs.gnu.org, bug-autoconf <at> gnu.org, Bruno Haible <bruno <at> clisp.org>,
	Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Date: Mon, 13 Jun 2011 14:46:39 -0600

[Message part 1 (text/plain, inline)]

On 06/13/2011 02:32 PM, Stefano Lattarini wrote:
>> +++ 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_()'?

Not quite, in coreutils' current usage.

Coreutils sets stderr_fileno_=9 in init.cfg, not TESTS_ENVIRONMENT;
which means that stderr can be changed after a call to setup_ but before
a call to warn_.  Thus, we want to output to $stderr_fileno_ (which is
9, and is always the original stderr), even during a test where stderr
has been redirected somewhere else.

> 
> 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

But setting things during TESTS_ENVIRONMENT does seem a bit more robust.
 Or rather, I think that the best action is to set stderr_fileno_
alongside the code that does the redirection; if it is TESTS_ENVIRONMENT
that does the exec 9>&2, then TESTS_ENVIRONMENT does seem like the saner
place (rather than init.cfg) for setting stderr_fileno_.

> 
> 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)?

Not possible to portably sniff out closed fds; quoting the autoconf manual:

> Don't rely on duplicating a closed file descriptor to cause an
> error.  With Solaris @command{/bin/sh}, when the redirection fails, the
> output goes to the original file descriptor.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.