At Sat, 13 Mar 2021 20:57:20 +0700, Robert Elz <[email protected]> wrote: Subject: Re: odd ATF failure for sh: ulimit_redirection_interaction failed > > OK, I see what is going on now. > > The difference for you is your initial ulimit -n > value. Not that it is big, but that when > reduced the way that test does it, getting > smaller and smaller till < 16, it happens to > land on a value < 10 as the first such limit > it tries. Using the default max fd value > doesn't do that, it reaches 15 or something > and stops. sh does not work well with less than > 10 available fds.
Heh. I landed on very nearly that clue when I started tracing the
script, but I didn't quite realize the implications!
Thank you very much for figuring it out!
It turns out of course that I had made a typo in my /etc/login.conf and
I had accidentally given my rootclass a soft limit of a very small
number of open files, just 64. On the good side, /usr/tests was the
only thing that seemed to run into any problems with this! (But of
course that was just for root shells -- my normal userid had 2000)
> But first, make sh give a better inducation what
> the problem is when this kind of thing does
> happen.
Yes, Please!
> When there are redirections in builtins, the
> existing fd (if any) must be moved elsewhere
> so it can be restored after the builtin exits.
> sh always moves to a fd > 10 for this use.
Ah, that explains to me better what that code is doing and why.
> ps: attempting to follow fd usages inside sh
> is not something for the faint of heart.
Indeed. As I was staring at it a couple of weeks ago I was
coincidentally reminded of Gosling Emacs -- maybe that sh code could
borrow Gosling's skull and crossed bones comment from his display.c :-)
--
Greg A. Woods <[email protected]>
Kelowna, BC +1 250 762-7675 RoboHack <[email protected]>
Planix, Inc. <[email protected]> Avoncote Farms <[email protected]>
pgpNvYPAoeT5c.pgp
Description: OpenPGP Digital Signature
