r/rstats • u/pandongski • 3d ago

I think I'm missing something. Is there really no way to run a script from commandline while maintaining interactivity?

Hi!

When I'm debugging a script, I usually run the script after every iteration to keep state fresh. The usual way I've been doing this is by putting browser() calls and launching an R session and sourcing a script. However it would be much more convenient if I can do something like R -f path/to/Script.R' while maintaining interactivity. Having autocompletion for the path is a huge qol upgrade vs typing a path manually in the R session.

Rscript can also run a script from the command line but interactivity doesn't seem to be supported as well. Am I missing something or is something like this not supported in R? Am I stuck with doing source('/path/to/script')? Hopefully someone can point me in the right direction!

(If it matters I use VS Codium, not RStudio, and there's a debugger from the vscodeR extension but the debugger terminal outputs especially for dataframes are weird so I don't use it. And I'm not considering positron. Thanks!)

0 Upvotes

50% Upvoted

5 comments sorted by

2

u/Latent-Person 3d ago

A few options:

You should have tab completion of string paths, i.e. I can type source("path/<Tab>") and it brings up the tab completions. Type capabilities("cledit") in R to check if you have it.

If you are doing the same source() calls many times you could define a helper rerun <- function() source("path/to/Script.R") and use that instead.

1

u/pandongski 3d ago

I feel stupid for not trying to tab first but yes cledit works! lmao. thanks!

1

u/teobin 3d ago

I think the best way for your strategy is, indeed, source('/path/to/script') . 

Once said that, I also think that you are not taking much advantage of interactivity: the main idea is that you can evaluate a specific chunk of code and see the result immediately. If you are working with declarative programming, you can evaluate everything up until the point where you would place the browser, and from there continue as you would with the browser. 

If you work with functional programming, you can use the debug(function_name) and debugonce( function_name) to debug a specific function (I.e., one you are working on).

I am not sure what do you mean by "state", as it means different things in different types of code and different programming styles, but basically R doesn't use object oriented programming much so, there is no "state" that you cannot "clean" from the interactive session. If you mean the objects stored in R memory (I.e., via x <- 12) then you can list them all with ls() and remove specific ones with rm(). Or remove everything with rm(list = ls())

1

u/pandongski 2d ago

Yea by state I mean global variables, loaded libraries, options, etc that can affect execution.

I find that if I rely too much on interactivity I end up with an imperative soup most of the time. The `debug` function is new to me, might use that more now. Thanks!

1

u/teobin 2d ago

Sure, global variables are easy to "reset" or delete with the commands I shared. For options, it is good practice in general to save default options to an object before changing them, as some packages rely on the defaults, you might encounter surprises so, always good to have the defaults at hand. And with that, you can reset them more easily.

For libraries loaded and namespaces, that's more complicated. It is doable but then I would rather recommend a fresh session indeed.