At Sat, 13 Mar 2021 20:57:20 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> 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 <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpXZNVK80aiw.pgp
Description: OpenPGP Digital Signature