Re: [Bug-tar] tar 1.24: OpenBSD testsuite failures

[Paul Eggert]

On 10/27/10 15:07, Eric Blake wrote:
> I know exactly WHY bash and other shells are trying to dup() to 10 or
> greater - they MUST preserve the shell's std fds for commands after the
> temporary redirection done by ': <&-'.

Ah!  Thanks.  The light dawns.  So my test was too strict.  Can people
please try the following test instead?  This parenthesizes the ":", so
that the shell need not preserve the stdin fd.

   if (ulimit -n 10 && (:) <&-) 2>/dev/null
   then echo OK
   else echo Houston we have a problem
   fi

This works for me with Bash and Dash (Ubuntu 10.10).  On Solaris 10 it
works with /bin/sh and with ksh and zsh.  It fails with pdksh and
ksh93 on Ubuntu 10.10; this isn't great, but it's good enough for a
tar test script.  Eventually people can get around to fixing their
shells: the file-descriptor-10 trick is not needed for subprocesses,
so the above test should work in any decent shell.


> At this point, I think that tar should fix its testsuite to use a larger
> ulimit -n setting; 10 is just too small for most shells out there,
> whether or not you also consider this a shell bug.

But that would break the test.  The test depends on starting tar with
a known number of available file descriptors.  With ulimit -n 13,
there's no portable shell-script way to know exactly how many file
descriptors are available.

> In fact, bash is *silently* losing stdin for all subsequent commands.

That is clearly a bug in bash.  Have you filed a bug report?  I can
give it a whirl if you haven't.

I agree that Autoconf should document this business.  What a mess!