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!