Running R well on LINCOMM: scripts vs. the console

Why a saved R script is the right way to run real work on LINCOMM, when the interactive console still helps, and how to keep package installs from slowing every run.

There are two ways to run R on LINCOMM (Linux Community Servers): typing commands into the interactive console, or running a saved script. Both have a place, but for the real work you came to LINCOMM to do, a script is almost always the better choice. This page explains why, and covers one R-specific habit that saves a lot of time.

The two ways to work

The interactive console (you start it by typing R) runs one command at a time and shows you the result immediately. It's ideal for exploring: poking at a dataset, trying a plot, checking what a function returns.

A script is a plain .R file holding the whole analysis, which you run start to finish:

Rscript analysis.R

Why a script wins for real jobs

Once you know what you want to compute, a script beats the console for three reasons:

Reproducibility. A script is the exact, complete record of what you did. Run it again and you get the same result. Console history is easy to lose and hard to trust.
It runs unattended. LINCOMM is for long jobs. A script started inside tmux runs to completion on its own, even if your connection drops — you don't have to sit and feed it commands. See Keep work running with tmux and How to run and manage jobs on LINCOMM.
It travels. A script with relative paths runs unchanged on your computer and on LINCOMM, and you can share it with a colleague. See How to use relative paths in R.

Keep package installs from slowing every run

R scripts often start by loading packages, and a common habit is to call install.packages() for each one at the top. That reinstalls everything every single run — slow on LINCOMM, and annoying every time you reopen the script locally. A better pattern installs only what's actually missing:

packages <- c("dplyr", "ggplot2", "readr")
missing <- packages[!(packages %in% rownames(installed.packages()))]
if (length(missing)) install.packages(missing)
invisible(lapply(packages, library, character.only = TRUE))

This checks what's installed, installs only the gaps, and then loads everything. Helper packages such as pacman (via pacman::p_load()) do the same thing in one line, if you prefer.

One related gotcha: when a script installs packages without a person watching, R can stall waiting for you to pick a download mirror. Set one explicitly near the top so an unattended run never hangs:

options(repos = "https://cloud.r-project.org")

A good working pattern

The two modes work best together. Explore in the console until you know what you want. As soon as a piece of code works, move it into your .R script. When the script is complete, run it with Rscript under tmux for the full job. You get the speed of exploration and the reliability of a script.

Limitations and trade-offs

A script is less convenient for open-ended exploration, where you don't yet know your next command. That's exactly what the console is for.
Don't rely on a saved workspace from a previous session to make a script work. A good script runs correctly from a clean start, loading everything it needs itself.