[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Avoid passing autotest job fds to test groups.

From: Ralf Wildenhues
Subject: Re: [PATCH] Avoid passing autotest job fds to test groups.
Date: Wed, 21 Jul 2010 21:52:57 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Eric Blake wrote on Wed, Jul 21, 2010 at 08:22:15PM CEST:
> On 07/21/2010 12:06 PM, Ralf Wildenhues wrote:
> >> But maybe we want to do a global:
> >>
> >> for i in 3 4 5 6 7; do
> >>   eval exec $i>&-
> >> done
> > 
> > (why not just exec 5>&- 6>&- 7>&-?)
> Easier to extend if we wanted to clear out to fd 63 or some such (if seq
> were portable, then 'for i in $(seq 63); do...' would be easier than
> writing 60 >&- instances).  But yeah, it makes more sense to only clear
> what we will explicitly use, rather than to clear arbitrarily high.

$ ksh -c '( exec 17>&-)'
ksh[1]: exec: 17: not found
ksh -c '( fd=17; eval exec $fd\>\&-)'
ksh[1]: eval[1]: exec: 17: not found

It is not portable to use fds higher than 9, and the above eval had
quoting problems too ;-)

> > We don't do anything with fds 3 and 4; either we consider them special,
> > then shouldn't close them for that historical reason, or we could just
> > use them for internal purposes.  Or decide now not use them because
> > we've never done so (and our users may have come to rely on that fact).
> We also document that users cannot rely on shell 'exec 3>file' to be
> preserved over an exec*(2) call (that is, fds 3 or larger may be marked
> cloexec when opened by the shell), and that other shells explicitly
> close all inherited fds 3 or larger on startup (that is, even if an fd
> is not cloexec in the shell's parent, it might be closed rather than
> inherited to the shell script body).  So, on thinking about it more,
> there is no portable way to write a test that relies on external
> inheritance of an fd >= 3 opened by the parent of the testsuite; and
> within a portable test, you can use only fds 3 or larger only so long as
> you stick to shell constructs (you can't expect your C program or a
> subsidiary script to see those fds unless you used the shell to
> duplicate it onto one of the 3 standard streams).

This paragraph assumes that the portability requirements of some user
package are roughly the same as those Autoconf assumes for itself,

> > But anyway this still means that users wanting to pass extra fds to test
> > groups, should know that 5, 6, and 7 are reserved by Autotest, at least
> > for passing from outside the testsuite.  And probably that 5 is better
> > avoided inside as well (I'm not sure if that's necessary, but it might
> > be at some point).
> Yeah, documenting that fd 5 is reserved for autotest logging may be
> worthwhile.  But I don't see that holding up 2.67.

Of course not.  Finishing 2.67 is more important than these details.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]