[Wellington-pm] question about 'system', and other methods for calling os functions

Ewen McNeill perl at ewen.mcneill.gen.nz
Tue Apr 19 03:37:33 PDT 2011


On 2011-04-19 22:01 , Richard Hector wrote:
> Can anybody suggest how to call an external function in such a way that
> those extra handles are not visible?
>
> I've tried forking, then closing them in the child before calling system
> (I know that means 2 forks; if it had worked I'd have looked at exec
> instead), but get the same result.

I'd expect fork()/exec()/waitpid(), in such a way that a shell doesn't 
get invoked, to be the most reliable way of having low level control 
over what environment/file handles/etc is passed to the underlying 
program.  The perl fork()/exec() fairly closely mirrors the underlying C 
library.  (A system() call, particularly one with shell syntax in the 
command line passed to it (including a single string with spaces) will 
generally be run via a shell, which will do its own thing with the 
environment/file handles/etc.)

You may be able to explicitly set the (unix) FD_CLOEXEC flag on the 
relevant file descriptors before the system() call (which should be 
doing fork()/exec()/other stuff under the hood on a Linux system), sort 
of like the reverse of the example towards the end of this page:

http://aaroncrane.co.uk/talks/pipes_and_processes/

but I'm not sure it's worth the effort.

That said, I'm unable to find a combination of perl+LVM tools amongst, 
eg, my Debian systems that reproduces that behaviour with:

sudo perl -e 'system("lvdisplay");'
sudo perl -e 'system("lvcreate");'

so possibly the versions on those systems have been fixed not to issue a 
warning (it's basically a debug warning), or otherwise handle things in 
a more graceful fashion.  Or possibly a more involved Perl program is 
required to trigger the behaviour.  (I note an obvious lack of source 
snippets, or specific version information, in the original message...)

Ewen

PS: Depending on your use case, various kludges to just hide the warning 
messages may be appropriate.


More information about the Wellington-pm mailing list