[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [Bug-tar] tar 1.24: OpenBSD testsuite failures
Date: Wed, 27 Oct 2010 16:38:57 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101006 Thunderbird/3.0.9

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

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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]