Robert Elz <k...@munnari.oz.au> wrote, on 30 Jul 2019: > > | However, they are easily preventable, so why not do that? > > Because in practice they never occur. I haven't seen a genuine > ENFILE in decades now I think - even provoking one is getting to > be impossible,
I agree ENFILE pretty much never happens these days. > and the only way a shell can get to the EMFILE > limit in any rational system is by decreasing the limit with a > (non-standard) use of the ulimit utility -- other processes might > (with some effort) be able to reach it, any shell running a > standard script simply cannot True if the script is run from a login shell (or subshell of it). If the script is run from a program that is already near the limit (and has no fd's marked close-on-exec), then it's entirely possible. I believe 32-bit versions of Solaris have the default limit set at 255 (because the 32-bit FILE structure has the fd as a uchar). > So, we have errors that aren't going to happen, I'll admit that EMFILE is rare, but given a combination of the above factors it certainly can happen. > and you're trying > to convince me to slow down one of the few parts of the shell where > execution time really matters so I can check for them. Really? Slow down? You jest. The shell is making a system call to open a directory. The time taken to check the errno value is negligible in comparison to that. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
