R_Interactive decision to halt execution during errors

Zed A. Shaw zed.shaw@ubc.ca
Wed, 21 Aug 2002 23:28:25 -0700


I'm currently trying to use R as a back-end from an interface (you may have
seen me on the help list), and I'm running into something that is rather
confusing.  The following lines in main/errors.c of R 1.5.1:

439:    if ( !R_Interactive && !haveHandler && inError ) {
440:        REprintf("Execution halted\n");
441:        R_CleanUp(SA_NOSAVE, 1, 0); /* quit, no save, no .Last, status=1
442:    }

Which seems to not make any sense at all.  I've scoured the code and can't
figure out what the rationale is for halting execution simply because the
input is not interactive.  I'm assuming the rationale was that, if input is
not interactive, then R is running as a script interpreter, but this isn't
the case since the stdio can be redirected in different ways (and actually
this is encouraged in the documentation).

R_Interactive is determined by a call to isatty(0) in unix/system.c which is
used in various places to control how R interacts with the user.  The
problem I see with this is that, there is no mode for "not interactive, but
don't quit" or "proxy mode".  I assumed --slave would do this (as, that
seems to be what the docs imply), but it doesn't.

So, is a patch in order, or is there another way around it?  I'm thinking,
the above if statement should have one additional and case for !slaveMode,
so that it can be run as a back-end even though the terminal is not
interactive.  Either that, or I can somehow install an error handler and
this code will be avoided.

I can do the patch for this, unless someone has a better way to fix it.  Let
me know what you think.

Finally, having read through most of this code, I feel that it is a bit
confused as to whether R is an interactive console or a script interpreter.
The above code assumes that, if R is not interactive, then it is a script
interpreter.  Yet, there's no real way to tell R to simply run a script file
other than sending it through stdio.  Effectively, the stdio channel becomes
confused with the dual purpose of being an interface or a file stream with
no way for R to differentiate.  I would prefer to see R act like most other
scripting languages:  stdio is reserved for interaction with the user and
does not abort on failure like above.  Meanwhile, a --script option is used
to run a given script like perl or python does, and would be expected to
halt on errors.  Does that make sense?

Anyway, let me know the best course of action.

Zed A. Shaw

r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch