Using R — Standalone Scripts & Error Messages

This entry is part 8 of 21 in the series Using R

Open-source R is an amazing tool for statistical analysis and data visualization. Serious R gurus have found ways to do just about anything entirely within the R environment. Nevertheless, there are many of us who wish to plug R into larger, multi-language frameworks where business logic will be handled by another language and R will be primarily responsible for analysis.  This can be an excellent division of labour but requires that you first get a handle on R’s warnings and errors and how they are passed upstream.


The easiest way to  encapsulate blocks of functionality for use by other programs is to create Unix-style, independent executables that can be invoked by other programs. (There are also many packages that allow R to be called interactively from within another language but they are beyond the scope of this post.) When writing standalone scripts for R you should use the Rscript executable that is distributed with R. You can learn more with Rscript --help or read the documentation. Rscript has the following advantages over command-line R:

  • It is an executable and takes a named file as an argument.
  • Additional arguments can be passed in on the command line.
  • Default settings are equivalent to R command line arguments --slave --no-restore.

A simple executable script would look like this:

Invoking the script is just like any other shell script:

If you are familiar with R programming, this is really all you need to get started with one caveat — What happens when things go wrong? How can a calling function trap errors and respond appropriately? The rest of this post will address the text strings that are generated for warnings and errors and how they can be modified and redirected. True error handling within R and the use of the tryCatch() function is idiosyncratic enough to warrant a separate post.

Internal settings for warnings and errors

While R has no command line arguments that affect warnings and errors, there are several internal ‘options’ that control the generation of warning messages. You can learn about all of them by typing ?options at the R prompt. Those options related to warnings and errors include:

The most useful of these is ‘warn’ which can be used to make R shut up about minor stuff:

Redirecting output

To begin at the beginning we have to know where warning and error messages go when R is first started up. In An Introduction to R we read:

Warning and error messages are sent to the error channel (stderr).

Just as R has a source() function that causes R to accept input from a connection (a file or URL), it has a complimentary sink() function that causes R to redirect output to a connection (file, stderr, or stdout). You can read up with ?source and ?sink but sometimes the best learning happens through experimentation.

Here is a script which experiments with options(warn) and the sink() function.

Just copy and paste this script and make it executable and then run it with shell level redirects to observe the behaviour of the sink() function:

When working together with other programmers in a larger framework, we are sometimes asked to direct certain categories of output to either stderr or stdout for processing by whatever code is invoking our script. Hopefully this example is enough to get you started writing some small, robust, Unix-style lego-bricks of functionality that will play nice in a larger framework.


If your Rscript is going to source files that contain S4 class definitions you will run into the following error:

This is because Rscript does not, by default, load the “methods” package.  Check out the “attached base packages” in each of the following:

To solve this problem you only need to load the methods package at the beginning of your script with:


Series NavigationUsing R — Calling C Code ‘Hello World!’Using R — Working with Geospatial Data
This entry was posted in R and tagged , , , . Bookmark the permalink.

Comments are closed.