jt@toerring.de (Jens Thoms Toerring) writes:
> Connie <yeconnie@gmail.com> wrote: 
>
> You mean your PERL script will be exec()ed by other (non-Perl)
> programs? Then I guess you shouldn't have to worry too much about
> that, the callers should consider which file descrptors they want
> to leak to an exec()ed program, they shouldn't expect you to do
> their cleaning up.

This isn't a really sensible piece of advice. The callers may just not
care and to point a finger at someone, crying 'thas is his/ her fault!!1'
isn't going to solve an eventual technical problem.

> Mentioning this as a possible problem might be nice - but actively
> closing files is not necessarily the right thing to do. Perhaps
> someone clever actually wants one of the files to be inherited by
> the child process you exec() and why would you keep her or him from
> doing that?

The obvious reply would be 'because I execute the child for a
specific purpose and nobody has any business "clevering around" with
it'. If it applies or not depends on the actual situation (probably
not for a xterm spawning a shell, certainly if running with
elevated privileges to enable someone to do a particular task he/she
would ordinarily not be allowed to do).
 
>
> I fear that would be rather difficult to do in a portable way.
> I guess you would have to iterate over all possible file des-
> criptor numbers and check for each of them if its an open file.

It is somewhat simpler:

long fd;

fd = sysconf(_SC_OPEN_MAX);
while (fd > 3) close(--fd);

[assuming that STD(IN|OUT|ERR) should remain open]

A better, but not universally portable solution, would be to close
everything > 2 listed in /dev/fd (supported at least by Solaris and
*BSD and indirectly by linux, through symlink /dev/fd ->
/proc/self/fd).

[ Post a follow-up to this message ]