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

Re: Generic system() replacements

Thread Previous | Thread Next
From:
Paul Fenwick
Date:
June 17, 2008 19:56
Subject:
Re: Generic system() replacements
Message ID:
48587956.3030000@perltraining.com.au
G'day Jan / p5p,

Jan Dubois wrote:
> On Tue, 17 Jun 2008, Paul Fenwick wrote:
> 
>> * Returns the exit value of the process (the full 16 bits on Windows),
>>   rather than requiring pain and suffering with $?.
> 
> On Windows the full exit status is actually a signed 32-bit integer,
> so it doesn't even fit into $?.

I stand corrected then.  IPC::System::Simple *should* return the full 32 bit 
integer, as it passes back what's returned by Win32::Process' GetExitCode(). 
  I'll go write some tests cases to ensure this is the case (currently I'm 
only testing with 8 and 16 bit returns).

> I think we should implement
> ${^CHILD_ERROR_NATIVE} on Windows to hold the full value (VMS already
> does this).

I agree with this sentiment, especially if ${^CHILD_ERROR_NATIVE} isn't 
doing anything else on Windows.

> There is also another bug in the Windows system() implementation in
> that it will execute a program twice if it returns a status of -1
> because that value is used internally to mark a failed invocation.

Ouch.  That's just doubly painful.  Execute the command twice, and then not 
have a way of being able to tell (from the exit status) if it executed at all.

I definitely have that bug when IPC::System::Simple is invoked with a single 
argument, since for single-arg system ISS always uses Perl's system() 
underneath.  The multi-arg system and capture() (replacement backticks) 
shouldn't suffer from this, since they always use Win32::Process (and never 
the shell).

> Isn't POSIX::WEXITSTATUS() what you are looking for?  I'm not sure if
> it works correctly on Windows, but it would probably be best to fix it
> there.

The POSIX WIF* macros would be perfect, but can't they can't be depended 
upon.  While POSIX seems to always export the WIF* calls, on a number of 
systems they croak with a "not defined POSIX macro" or "not a valid POSIX 
macro" error.

IPC::System::Simple goes through quite a bit of sniffing to check if a 
system defines the macros, and if the macros are sane.  If not, it defines 
its own.

Also, as you've mentioned, they don't work usefully on Windows (the signal 
bits are never set, the core-dump bit is never set, the exit bits are 
truncated to an 8-bit return).  Plus there's some effort required to get the 
signal name given a signal number (for systems where signals make sense).

IPC::System::Simple already does all this work, I just need to put together 
an interface that makes it accessible to people who don't necessarily want 
to use the IPC::System::Simple way of running commands.

All the best,

	Paul

-- 
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About