> I believe:
>
> system(cmd, "http://www.google.com")
>
> would also skip the shell entirely, since you are providing more than
> one argument to system.

Correct. It is only the one argument form that uses the shell.

> Seems like a dodgy sort of design to me.  I gather it comes from
> trying to merge system() and exec() from the C library, probably for
> systems that don't have a concept of fork().  From JJ's post, I gather
> that Perl might be the source of this chimera.

I wish popular languages would think about these decisions. Two APIs
for this would be much better.

The first could be Kernel::exec, and would simply run the process
given. No shell interpretation would ever be done on the argument(s).
Give it one string, and that's the program it runs. Give it multiple
strings to pass multiple arguments.

In fact, I'm willing to bet that 99% of the time, one already has the
command and arguments separated into a list, and one rarely if ever
wants to use the one-argument-use-the-shell form of exec (or system).

A second routine, "Kernel::exec_cmd" let's call it, could take in
exactly one string, and would pass it through the platform's command
interpreter. This would be documented with all the ugly warnings that
are required so people don't write

  exec_cmd( "ls #{user_input}" )

The confusion that could be cleared up by separating these out is a
big win I think. Another benefit is that the Unix implementation of
exec_cmd could simply be

  exec( "/bin/sh", "-c", arg)

-JJ