develooper Front page | perl.perl5.porters | Postings from June 2008

Re: Generic system() replacements

Thread Previous | Thread Next
Paul Fenwick
June 17, 2008 17:25
Re: Generic system() replacements
Message ID:
G'day David / p5p,

David Golden wrote:

> ++ for the attempt.

Thank-you. ;)

>> * Same calling syntax and semantics as CORE::system
> I disagree on the latter.  It's not a drop in replacement due to
> return values and exceptions, so it's not the same "semantics" (at
> least as I interpret the word semantics).

Point well-made.  Same syntax, similar semantics (single-arg system uses the
shell, multi-arg system doesn't).

>> * On Win32 it uses Win32::Process to try and spawn additional processes,
>> which I understand to be quite fast.
> Is it any faster/better than core system()?  They both use the same
> Win32 API call inside.

It's certainly not faster than the core system, although it is faster than
some of the techniques (described elsewhere in this thread) which spawns off
helper processes.

>> * Multi-arg system() never invokes the shell under Win32, even though
>> CORE::system will.
> Another semantics change -- though I'll admit this one just might be
> an improvement.

I actually consider multi-arg system calling the shell under Win32 to be a
bug[1].  It happens as a fallback when Perl can't find the command itself.
Unfortunately this means it's practically impossible to detect if the
command ran and returned an exit of 1, or the command was not found and the
shell returned 1 to indicate that.

Extra fun can be had by setting PERL5SHELL first.

> One of the things I haven't been able to understand from the docs is
> whether I can actuall get $? if I want it -- or put different, can I
> find the number of a signal that killed it without parsing the
> exception message.

With the current release, I would not depend upon $? being set reliably.
However providing a way to access the information that's normally stored in
$? more easily has long been on my wishlist[2].

In the next release, there will be an interface to get the exit value,
signal name, signal number, and core dump status, along with a mechanism to
supply your own $?.  Suggestions for better names than unpack_child_error()
are welcome! ;)

I'm also leaning heavily towards making the ISS exceptions into real
objects, which provides for a much cleaner interface:

	eval {

	if ($@) {
		say $@->command;
		say $@->exitval;
		say $@->signal_no;
		say $@->signal_name;
		say $@->dumped_core;
		say "Pretty printed error: $@";

Thanks for the feedback, it's very much appreciated! ;)




Paul Fenwick <> |
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About