On Jan 8, 2008, at 3:19 PM, JJ wrote:
> 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.  For  
whatever reason it came to pass that Kernel#exec on windows is  
actually a Windows version of fork/exec making exec
non-portable.

> 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

You are describing "Kernel::system" without the funny two-element  
array caveat.

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

I just made up the name 'run'.  I don't think there are standards  
that specify such an interface, which is why exec/system have been  
munged, I guess.

Gary Wright