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

[Eric Blake]

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature