Tongue-in-cheek answers: Because having another module to do "system" doesn't actually make things simpler?

There's no denying that IPC::System::Simple is yet another wheel. It overlaps with a lot of the existing modules that handle calls to external commands. However it exists specifically to present the smallest possible learning curve for someone who wants to Do The Right Thing when calling external commands, but doesn't care how.

I can take someone who has almost no understanding of how Perl works, who has a full bladder, and a flight to catch in five minutes, and still teach them how to use IPC::System::Simple. I can do it in one slide in a classroom.

When I can tell people they can take their ugly, legacy Perl code, and replace each instance of system() with run() and suddenly get error checking and detailed diagnostics for free, that's a powerful force. If they want anything more than that, that's what all the other modules are for.

Because having yet another special case of how things work on Windows doesn't make things simpler?

I agree entirely! This is specifically making the module work the same way under Windows as it does everywhere else. Let's take your example:

For example, you suggest that a multi-arg list never be passed to the shell. So how would you replace/handle this call to "system":

system("echo", "%PATH%"); # works fine on Win32

And here's the crux of the problem. Currently, that does work fine under Windows. According to the documention in perldoc -f exec, it shouldn't:

Using an indirect object with "exec" or "system" is also more secure. This usage (which also works fine with system()) forces interpretation of the arguments as a multivalued list, even if the list had just one argu- ment. That way you're safe from the shell expanding wildcards or splitting up words with whitespace in them.

@args = ( "echo surprise" );

exec @args;               # subject to shell escapes
                          # if @args == 1
exec { $args[0] } @args;  # safe even with one-arg list
[download]

Under Windows, Perl's system() is currently doing exactly what it shouldn't do, interpreting shell metacharacters and commands when called with multiple arguments. In my opinion, this is a bug in Perl.

So, I guess my real question should be this. At what point does IPC::System::Simple break bug-for-bug compatibily with Perl, and do what Perl says it should do, rather than what Perl actually does?

According to the documention in perldoc -f exec, it shouldn't:

Perl documentation is Unix centric. It would be nice if there was at least a note in perlfunc for all functions that are cited in perlport. From the latter, regarding system:

As an optimization, may not call the command shell specified in $ENV{PERL5SHELL}. "system(1, @args)" spawns an external pro‐ cess and immediately returns its process designator, without waiting for it to terminate. Return value may be used subse‐ quently in "wait" or "waitpid". Failure to spawn() a subprocess is indicated by setting $? to "255 << 8". $? is set in a way compatible with Unix (i.e. the exitstatus of the sub‐ process is obtained by "$? >> 8", as described in the documen‐ tation). (Win32)

Of course, as you've demonstrated, this is incomplete as well, since apparently Perl may or may not call the shell based on some complex, undocumented logic.

Worth noting here that you should consider what IPC::System::Simple does in the case of run(1, @args).

I can take someone who has almost no understanding of how Perl works, who has a full bladder, and a flight to catch in five minutes, and still teach them how to use IPC::System::Simple. I can do it in one slide in a classroom.

While teaching is a wonderful thing, I don't think modules should necessarily be designed to optimize teaching. In this case, I think the simplicity obscures critical understanding of just how tricky portable system calls are. Moreover, it leaves them with nothing to fall back on when their needs develop beyond IPC::System::Simple.

As I look at the code of IPC::System::Simple, it seems to me that it does two primary things:

• Encapsulates substantial logic for extracting return codes and exit signals from $? as portably as possible

• Throws exceptions on errors or, optionally, certain return codes.

I think the first would be ideally extracted into a module of its own so that it could be used with other alternatives for system as well.

The second is a coding style preference.

I personally don't like the "prepend an array of acceptable return values" feature -- I think that's another special case that makes things less simple. It also makes it really challenging to read code unless one already knows what IPC::System::Simple does:

use IPC::System::Simple qw(run);

my $exit_value1 = run("foo", @args);

my $exit_value2 = run([0..5], "foo", @args);
[download]

The first is pretty intuitive. The second is not. Again, from a teaching perspective, I'm not sure that's the right approach.

Imagine an IPC::System::ExitValue module instead:

use IPC::System::ExitValue qw/exit_value exit_signal/;

system( "foo", @args );
croak "foo stopped early" if exit_signal($?);
my $exit_value = exit_value($?);
[download]

That would be trivial to write with the guts of IPC::System::Simple. And it could be used with other modules that substitute for system (as long as they preserve $?).

If you really want to help throw exceptions for anything other than some exit values:

use IPC::System::ExitValue qw/assert_exit/;

system( "foo", @args ) and assert_exit( 0 .. 5 );
[download]

I think that kind of approach would keep things simple for teaching but provide much greater functionality as students' and other Perl programmers' needs progress.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.