On Wed, 29 May 2002, Tobias Reif wrote:

> It's not a bug, it's a potential RCR for a probably useful and feasible
> improvement. I do not want to need to know "how things work" regarding
> CMD.EXE etc.; I want Ruby to handle that for me, if possible.

Consider this: if you want to give a commandline command and get it's
return code, stderr, and dtdout, you _cannot_ expect ruby to know whether
you are calling a program or a builtin.

Why?

Because that would require ruby to be portable across not only operating
systems, but shells. For example, what should issue("echotc") do on
bash, ks, command.com, etc? On zsh you get "echotc: not enough
arguments" on stderr... ;)

Ruby can hardly be a true mindreader, although it sometimes seems so.
You want it to "know" that on Windows you want to pass you commands thru
cmd.exe -- but it cannot know that you don't actually want to use that
cygwin bash shell...

Which brings me to my send point:

If you want to use ruby as a portable scripting tool, you
have to limit yourself to ruby-builtins (ie. File.delete "foo.txt")
for system manipulations, and to running portable programs:
not identical commands, but programs.

For checking program success it seems that you cannot trivially access
it's stderr on all platforms (untill there is a portable open3.rb, at
least), but you should be able to rely on it's exit  code -- that's what
'system' returns.

system "program -lot -of -flags" || raise "program failed"

 -- Nikodemus