On 06/13/2011 03:39 PM, Stefano Lattarini wrote: > > [3] The $(SHELL), which here we assume is ksh with close-on-exec, does a > fork+exec to execute the test script; thus, when that script begins > its execution, it has the fd 9 closed (d'oh!, but expected now);
Oddly enough, it looks like it is _only_ 'exec 9>&2' that suffers from close-on-exec semantics; using '(blah) 9>&2' leaves fd 9 inheritable. So maybe the real fix is to do the redirection to a subshell or grouping {} rather than via exec, at which point even ksh and HP-UX sh will allow the original stderr to be inherited as fd 9 to the child script process: $ printf '#!/bin/sh\nexec >&9\n' > k $ sh k k[2]: 9: Generated or received a file descriptor number that is not valid. $ sh k 9>&2 $ sh -c 'exec 9>&2; /bin/sh k' k[2]: 9: Generated or received a file descriptor number that is not valid. $ sh -c 'sh k 9>&2' $ sh -c '(sh k) 9>&2' $ sh -c '{ sh k;} 9>&2' $ but I don't know if that will require some changes in automake's parallel-test driver setup code. And Autoconf should probably document that the close-on-exec semantics of some shells applies only to the exec builtin, since they do not happen to other redirections. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature