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.