5

I've been using the here package to make my projects more portable. It works great apart from when I use cronR to schedule some of my scripts. When I run my_script.R from Rstudio I get a message from library(here):

here() starts at /home/pd/projects/my_proj

When I set script.R to run using cronR I get a different message:

here() starts at /home/pd

Which is where my_schedule.cron is stored. Ideally I want to keep my_schedule.cron where it is. I can see from the logs that my_script.R runs fine apart from when it comes to saving data because the path used by here() is incorrect. Is there anyway to get the here function to detect the project dir when my_script.R is run from cronR or the terminal?

dnlbrky
  • 9,396
  • 2
  • 51
  • 64
Pete900
  • 2,016
  • 1
  • 21
  • 44
  • 1
    I would use cron manually and pass a parameter to R CMD BATCH command with the program path; parameter which value is retrieved with `commandArgs` -- cf. https://www.r-bloggers.com/passing-arguments-to-an-r-script-from-command-lines/ – Eric Lecoutre Oct 12 '18 at 09:03

2 Answers2

4

You can modify the command cmd that is usually created with cron_rscript() by adding cd to your project folder followed by the usual part:

cmd <- "cd /home/pd/projects/my_proj && /usr/lib/R/bin/Rscript ./my_script.R >> ./my_script.log 2>&1"
cron_add(command = cmd, frequency = 'daily', at = '18:00')
tomaz
  • 493
  • 4
  • 13
1

If the first line of your #rstats script is wd <- here(), I will come into your lab and SET YOUR COMPUTER ON FIRE.

Learn how to use environment variables 

wd <- Sys.getenv("HOME")
wd <- file.path(wd, "projects", "my_proj")

Or use the 'Additional arguments to Rscript' element in the cronR user interface to pass something extra to the Rscript and fetch it with commandArgs(). If you don't use the cronR interface but cron_rscript, use cronR::cron_rscript(..., rscript_args = "/home/pd/projects/my_proj")

args <- commandArgs(trailingOnly = TRUE)
if(length(args) > 0){
  wd <- args[1]
}
  • hahaha! Point taken....it seems my computer is a massive fire hazard at the moment! – Pete900 Oct 12 '18 at 12:27
  • Sorry, is there an easy way to get the relative location of another users project without using here? – Pete900 Oct 12 '18 at 14:37
  • Look to print(Sys.getenv()) when launching a script through cron to see which environment variables are available and use these. –  Oct 14 '18 at 18:52
  • You hard code `projects/my_proj`, ensuring that the script will fail if the project directory is moved relative to `HOME`. That defeats the basic goal of making the project portable... – Ista Nov 22 '18 at 16:35
  • @lsta, your point is exactly the same when you use the here package. See the here readme at https://github.com/r-lib/here where you exactly see the same issue that you point out. here just finds some root folder. It does not guarantee that your scripts will work if you change the folder structure inside your root folder. The whole point of the answer is that `Sys.getenv("your_project")` is a replacement of here. –  Nov 22 '18 at 21:01
  • @jwijffels I admit to not understanding the point of the `here` package. But I really don't get the advantage of your recommendation; if using the here package is an invitation to arson so is your method as far as I can tell. Moreover, the question asks for an improvement over the `here` package. I fail to see you your approach improves anything at all. – Ista Nov 23 '18 at 01:12
  • The question was how to use `here` with a cronR schedule. `You can't` as the cron schedule starts the R session on a different location than you would if you open an Rstudio project. So `here` does not find the files and is not portable. If you want to make it portable, you need to use environment variables as pointed out in the answer. –  Nov 23 '18 at 09:01