The original closing loop was implemented to make sure child proceses have a few dozen descriptors free when started. Another aspect is to ban inherited filedescriptors from reading data from the pty. That is a security topic. Not sure how hard it is nowadays to keep a filedescriptor secretly opened to a pty or tty and have it returned to the pool for re-use. On the old hpux multi-user system we had at the campus at that time, it was easy. That should be called a kernel bug, if still possible, I suppose. If secure, I'd suggest to limit the loop to close the lower 4000 or so.
The exit status of screen is not well defined, I am afraid, There are some invocations that report a count of avalable sessions through the exit status (what a hack), but --version should happily exit(0) . cheers, JW- On Fri, Feb 1, 2019 at 4:59 AM Lukas Waymann <invalid.nore...@gnu.org> wrote: > Follow-up Comment #1, bug #55618 (project screen): > > I didn't mention that this causes the screen executable to take much > longer to > start. (I think the command-line arguments don't matter.) > > Before: > > > $ time screen --version > Screen version 4.06.02 (GNU) 23-Oct-17 > > real 0m0.008s > user 0m0.000s > sys 0m0.009s > > > After: > > > $ time screen --version > Screen version 4.06.02 (GNU) 23-Oct-17 > > real 0m0.170s > user 0m0.057s > sys 0m0.112s > > > By the way, is the exit status of _screen --version_ intended to be 1? > > _______________________________________________________ > > Reply to this item at: > > <https://savannah.gnu.org/bugs/?55618> > > _______________________________________________ > Message sent via Savannah > https://savannah.gnu.org/ > > >
