> > 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.
>
> Yes, but in the Unix/C world exec() replaces the
> existing program and so exec() without fork() is a
> not-so-useful combination.

Well, I argue that exec() without fork() is useful in any world, but
it may not be available in some. It can be poorly emulated by
CreateProcess() and exit().

My point was not this though; it was simply that instead of having one
routine behave in two very different ways (exec via shell and exec
directly), there should have been two routines. Getting those confused
is the source of many, many bugs.

I would bet that any piece of code you gave me in Perl or Ruby (or any
other language that supports this idiom) that used system() or exec()
would have a very high chance of containing bugs related to this very
problem. I've seen it all the time.

> I think a better partitioning of the problem would be:
>
>    fork/exec:  craft what you need, only available on
>                *nix systems
>    system:     execute a command line via the
>                command-interpreter
>    run:        execute a program *without* using the
>                command-interpreter

Well, my exec and exec_cmd suggestions were meant to have analogs of
system and system_cmd that did the implicit fork on unix. My exec is
like your first exec, except there are two - one via the shell and one
via the system call.

My system is like your system, and my system_cmd is like your run.
We're speaking the same language; just using different words.

-JJ