Glad you asked. When the initial work started, Rscript
did not exist so there was no scripting tool. We take a small amount of
pride into beating Rscript
narrowly to a first release. Of
course, by now, Rscript
is more widely used as it ships
with every R installation but we still have some aspects we like about
r
: it is simpler and shorter, deals (in our biased) view
more sanely with command-line arguments via the argv
vector, always loaded package methods
(which
Rscript
finally came around to a good decade later) and still
starts faster. And r
is just to cool a command (in
relation to the trusted R
) so someone had to!
In the very beginning of littler
, we made an executive
decision to not echo each command output when we evaluate
commands in the read-evaluate-print loop. So 2+2
will be
evaluated silently: four will be computed, but not shown.
That made sense for scripts we wanted to be silent. The idea is that
user will add a print()
or cat()
as needed. If
you desire each step to printed, add a -p
or
--verbose
argument.
.Renviron
Another early decision was to make r
start
faster than the alternatives. Our r
is “just” a
small little binary. Whereas R
and Rscript
are
front-end shell scripts sourcing a number of things and setting them
dynamically, we determine values at compilation time and freeze
them into the binary. That may seem risqué but worked out just
fine. However, while we later added the ability to source
Rprofile
files (which contain R code we can evaluate) there
is no way for us to source the Renviron
files and to
modify the already running process. So if you want to source
Renviron
you could add an explicit
readEnviron()
to ~/.littler.r
or
/etc/littler/r
.
This is mostly an issue on macOS where the brain surgeons behind the
OS decided that r
is the same as R
. What can
we say? On that OS you may need to rename the build to lr
instead. Please send your complaints to Cupertino, California.
When the package is installed from source, it displays
*
* new binary $(TGT) installed in bin/ subdirectory"
* consider adding a symbolic link from, e.g., /usr/local/bin"
* on OS X, you may have to name this 'lr' instead"
* see the littler-faq vignette for more details"
*
where the variable $(TGT)
normally expands to
r
. As the text suggests you may want to create a symbolic link
from a directory in the to make the newly built binary available to
users. On Linux you may do
cd /usr/local/bin
sudo ln -s /usr/local/lib/R/site-library/littler/bin/r .
to create a link for r
in /usr/local/bin
.
On macOS, as suggested, you may want
cd /usr/local/bin
sudo ln -s /usr/local/lib/R/site-library/littler/bin/r lr
to create a command lr
instead; see the previous
question as to why. In either case adjust the source part of the
ln
command to where your binary is – which R can tell you
via system.file("bin", "r", package="littler")
.
Also note that e.g. the zsh has a builtin command
r
which may conflict, so using the explicit path of, say,
/usr/bin/r
or /usr/local/bin/r
or … may
provide an alternative.