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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature