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

From: Jim Meyering <[email-masked]>
Date: Mon, 13 Jun 2011 17:37:55 +0200

Eric Blake wrote:

> On 06/13/2011 07:36 AM, Jim Meyering wrote:
>> However, it looks like using "eval" didn't help at all.
>> What does this do on that system?
>>
>>     sh -c 'e=2; warn_ () { echo "$@" 1>&$e; }; warn_ x'
>
> $ sh -c 'e=2; warn_ () { echo "$@" 1>&$e; }; warn_ x'
> x
>
>>
>> This is what happens via tests/check.mk:
>>
>>     printf '#!/bin/sh\ne=9; warn_ () { echo "$@" 1>&$e; }; warn_ x\n' > k
>>     sh -c 'exec 9>&2; /bin/sh k'
>>
>> Does that evoke a warning for you?
>
> Yes:
>
> %     sh -c 'exec 9>&2; /bin/sh k'
> k: 9: Generated or received a file descriptor number that is not valid.
>
> But I think the reason that it invokes a problem is not because of the
> 1>&$e construct, but because HP-UX opens secondary file descriptors as
> cloexec or otherwise closing them at some point, so the '/bin/sh k'
> child process is not inheriting fd 9 from the parent process.

Ah ha!
That sounds like a syscall that needs to be gnulib-replaced in bash/zsh.
Of course, first we'd need to gnulib-enable a shell.

> Does anyone know the HP-UX counterpart to Linux' strace in order to see
> what syscalls are in use by the HP-UX shell, and why/where fd 9 is
> getting closed?

http://bhami.com/rosetta.html suggests the following:

  caliper fprof
  caliper ktrace
  trace (freeware)
  tusc (11+, freeware)

>> If so, does hard-coding the "9" help?
>
> No.

Thanks for investigating.