Rainer Weikusat <rainer.weikusat@sncag.com> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes: 
[vbcol=seagreen]
> 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.
 
[vbcol=seagreen]
> 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).

Sorry, but I've got to disagree: if the caller exec()s a new process
(s)he must be aware that file descriptors gets inherited by the new
process as it has always been part of what you have to take into
consideration when using exec(). And since this is a PERL module
Connie is writing it's normally not even an issue anyway since in
Perl all the files will have the close-on-exec flag already set
(except 0, 1 and 2), so they won't leak to what the module exec()s
- unless the caller for some reasons of it's own un-set it and then
the writer of a module should not assume to know better than the
caller. It only could become an issue if someone exec()s a Perl
script using the module e.g. from a C program, but then I would
stand by my opinion that the writer of such a program is required
to know what (s)he's doing. Actually, I don't appreciate it if I
try to use some tool and find that it tries to be too clever and
insists on keeping me from making "mistakes" (typically not even
mentioning it in the documentation) that aren't mistakes at all
but well documented methods of getting things done.

Regards, Jens
--
\   Jens Thoms Toerring  ___      jt@toerring.de
\__________________________      http://toerring.de

[ Post a follow-up to this message ]