Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I am having trouble sourcing a file into my Rmd file.
I have sourced files before and can not figure out why this one won't work. I have my working directory set to the correct spot. I have a file called projects in that I have my "index.Rmd" file and then I have a folder "scripts" with includes "chart_1.R".
So my work flow would be projects -> scripts. In projects I have index.Rmd and in scripts I have chart_1.R
source("scripts/chart_1.R")
I should be able to access the chart_1 file but I am not able to.
It gives me the error "Error in file(file, "rt") : cannot open the connection"
2 solutions...
Preferred Solution
Have you tried the here package? It's made just for things like this, and it might do the trick. Your solution would look like this:
Install the package; it's on CRAN: install.packages("here")
If you're not using R projects, define what "here" means by adding a blank file called .here to the projects folder.
Use code like the following:
source(here::here("scripts", "chart_1.R"))
Or,
library(here)
source(here("scripts", "chart_1.R"))
Basically here works like file.path, in that it generates a filepath. But it always starts with your base directory, according to rules spelled out in the docs.
Maybe this is overkill for your particular problem, but it's a wonderful package and worth trying out. It avoids using absolute paths, which render your code less reproducible if someone else were ever to download the projects folder to check out what you did.
Workaround
The knitr function current_input can get you the location of the .Rmd file, at least when used with the option dir = TRUE. And basename will get get you from a filepath to the location of the containing folder. So you could try this as a workaround:
source(file.path(basename(knitr::current_input(dir = TRUE)), "scripts", "chart_1.R"))
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed last year.
This post was edited and submitted for review last year and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
More of a conceptual question than a strictly coding one. I have an .R script dedicated to importing and generally cleaning my data. I have several different .Rmd scripts that use the data from the general cleaning .R script to run their specific analyses. I would like to be able to source("DataCleaning.R") at the beginning of each of the .Rmd scripts, that way I could reduce redundancy, but I'm getting this error:
'Pulling' is not recognized as an internal or external command,
operable program or batch file.
I could fix this problem by exporting and importing a .csv, but I'm kind of confused why source() won't work. I've tried it on a few computers now. Works fine in .R but not .Rmd. Would have sworn I've used it in .Rmd in the past. I reread the documentation on it. I couldn't find anyone else reporting this exact error message, but I'm trying to find the file containing the code to take a closer look at 'Pulling'.
QUESTION:
Does source not work in .Rmd, or is this a unique case?
UPDATE:
I managed to get the problem to go away by uninstalling both R and R Studio and reinstalling them. Updating them did not work. The code for source looked fine to me. Still scratching my head a little at this one, because it worked in a regular R script but not R markdown, and was giving me an issue across two different machines, both of which were resolved when I did the full reinstall. I suppose it's fixed for now, but not sure what it could have been.
This question was closed for nonspecificity and not providing reproducible code, but, again, those standards can't really apply in this case because it was a machine-specific problem. I just needed to know whether I was misunderstanding the role of the function. Hopefully the update addresses the critiques, but obviously feel free to close it again if not.
Yes source does work in .Rmd. Here's a reproducible example to prove it:
---
title: "Untitled"
output: html_document
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
fname = tempfile()
writeLines('print("hello")', fname)
```
```{r}
source(fname)
```
The error you are getting must be caused by the content of your external file.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I was working on R studio, I had a project with 2 .R files.
One is app.R, the other one used to be called test.R, and app.R was able to invoke it's functions without adding anything else, however, I renamed test.R to calculations.R
Now app.R cannot find any of its functions. I already checked the working directory and they're both in the same locations
What can I do to make app.R detect calculations.R?
That sounds to me like you defined your functions in test.R, also ran it there and than started your app. Once you define a function and ran it, no matter what script they are in, this function is within your global environment. That means that you can start your app, without sourcing your test.R script. However, you should follow the advice of #duckmayr, because in programming you rather want to make everything explicit.
In order to only have functions which are defined within your app environment, consider using the following command in the beginning of your script:
rm(list = ls())
This command will clear your enviroment, so that no unneeded functions, packages, objects and the like are within it.
It is my first experience in writing an R-package. I used roxygen2 by following the instructions given in this link http://kbroman.org/pkg_primer/
Everythig is working fine except few things.. there could be a simpler solution to solve the issues, but I am not finding clues what I am doing wrong. I hope someone here in this blog can give a solution to solve my issues.
First issue is about {\code\link{function-name}} in roxygen2:
In .R script I inlcuded this line:
#' #seealso \code{\link{s2a}}
After documenting (generating .Rd files) there is no hyperlink to s2a ,
in documentation s2a shows like a normal text not like hyperlink..
export(s2a) is listed out in NAMESPACE.
Is there any other place i need to modify ?
Second issue is about data():
I saved the dataset in .Rdata format and placed in the data/ in package directory. I also created the .R script in R/ as like following steps here http://kbroman.org/pkg_primer/pages/data.html
In DESCRIPTION file LazyData: true .
but when I type data(shh) in R console gives a warning message
data(shh)
Warning message:
In data(shh) : data set ‘shh’ not found
Any ideas is of great help:)
It's been a while since you asked this, but I was having the exact same problem with hyperlinks in documentation not appearing correctly, so for anyone who might be having a similar problem: Are you possibly viewing the development documentation? The links don't seem to work there. (You'll know this is the case if you see Using development documentation for your_function_name in your console output when you run ?your_function_name.)
The links should appear in the non-development documentation. To generate this you can try building and reloading your package, for instance by following the steps here: http://r-pkgs.had.co.nz/man.html#man-workflow-2
I have seen many related answers here,but i didn't get a proper way to solve my problem under windows system...
I know the link the similar question
I got that setwd() can locate the directory what i want,however,my R script may move to another directory without any modification,so I want to know the current file directory,becase there are expression like source(...),this called source file and the execution file under the same parent directory in a R project,how I can do?
any help appreciated.
You can get your current directory using the getwd() function and give it a name, say:
cpath = getwd()
Another useful function is the file.path, which can help you specify new directories with simple syntax. For example, you want to get the directory that is one level "above" the current directory, you can use:
upp.dir = file.path("..", "cpath")
This gives upp.dir as "../Your_Current_Dir". How about changing to another folder (called Folder_A) in current directory? Use:
folderA = file.path("cpath", "Folder_A")
These may help easy navigate the file system.
Basically, if you write scripts and those scripts depend on where they are, then you are Doing It Wrong.
Write code in packages. Parameterise functions to make them generally applicable. If you have folders with data in, then make one of those parameters a folder.
A script called with source() cannot reliably locate itself, but that shouldn't be a problem, because WHATEVER CALLED THE SCRIPT knows where the script is (it has to, or how else can it call it?) so it could pass that as a parameter. Something like:
> youarehere = "C:\foo\"
> source("C:\foo\bar.R")
and now bar.R can do setwd(youarehere) and it will work, even if it is badly written such that it relies on sourcing other code in its containing folder.
Or you can do:
> setwd(youarehere)
> source("bar.R")
in your calling function.
But really, its a fail, its a sign of badly written code. Use functions, write packages, use devtools, its really not that hard, then your code will work anywhere and you wont be writing stupid scripts that are a twisty turny maze of source() calls.
Stay classy.
I've heard it said that it is bad practice to use setwd() in a script.
What are the risks/dangers associated with it?
What are better alternatives?
It's an issue of reproducible code. If you specify a directory that doesn't exist on someone else's computer, then they can't use your code. This is particularly bad with absolute file paths, and particularly bad with Windows file paths (which are absolutely impossible to replicate on a Unix system).
My preferred solution is to specify that the user should be in the relevant directory on their own system before starting to run the code. If for your own convenience you want to put a setwd(...) right at the top of your code, where other people can notice it and comment it out as appropriate, but the rest of your code assumes only relative paths from that starting directory, that's OK with me.
Yihui Xie (author of knitr) feels particularly strongly about this:
https://groups.google.com/forum/?fromgroups=#!topic/knitr/knM0VWoexT0
Whenever you want to manipulate files, they are assumed to be under
the same directory of your source (e.g. Rnw documents). Then you can
always use relative paths and you will never need to setwd(). Using
setwd() contradicts with the principle of reproducibility, e.g. you
use setwd('foo/bar/') and the directory may not exist in other
people's computers. See FAQ 7:
https://github.com/yihui/knitr/blob/master/FAQ.md
And from the aforementioned FAQ 7:
You'd better not do this [change working directory inside knitr code
chunks]. Your working directory is always getwd() (all output files
will be written here), but the code chunks are evaluated under the
directory where your input document comes from. Changing working
directories while running R code is a bad practice in general. See #38
for a discussion. You should also try to avoid absolute directories
whenever possible (use relative directories instead), because it makes
things less reproducible.
See also: https://github.com/yihui/knitr/issues/38
I can't think of any particular issues with using setwd() in a script run on a server I manage as it does return an error which can be trapped with try(), and you can manage it. I have used setwd() when being lazy about paths - see below!
I use file.path() extensively in scripts production or otherwise. Working across the files in an input directory and putting the output graphics and reports elsewhere. So something along the lines of... (untested) This would be a bit tedious using setwd().
kInDir <- '~/Indir'
kOutDir <- '~/Outdir'
flist <- dir(path=kInDir, pattern='^[a-z]{2,5}\\.csv$')
# note I could have used full.names=T - but it's easier not to...
for (fnam in flist) {
# full path to the report file created
sfnam <- file.path(kOutDir, gsub('.csv', '_report.txt', fnam))
# full path to the csv file that will be created
ofnam <- file.path(kOutDir, gsub('.csv', '_b.csv', fnam))
#
# ok... we're going to process this CSV file...
r1 <- read.csv(file.path(kInDir, fnam))
#
# we''ll put the output from the analysis into this report file
sink(sfnam, split=TRUE)
# processs it... into a new data.frame k1
# blah blah blah...
#
write.csv(k1, file=ofnam, row.names=FALSE)
sink() # turn off this particular report file
}
Toward the better alternatives question:
I mainly use R for individual projects (meaning I'm the primary analyst). However, we do use these in projects which sometimes need to be shared with others.
RStudio - Projects
I have found RStudio's Projects functionality goes a long way to keeping your files organized. If other users also adopt RStudio, they will have the nice feeling of being able to open a single file ("*.Rproj") and have the project load in the same state you last saved it to.
ProjectTemplate
On top of this, I've found a new tool, ProjectTemplate that goes a step further! The technique the author developed is used to provide structure to what you are doing. Please go over to the website for more detail.
Though problems with setwd() have been targeted, I would like to add one more to the what are the alternatives part of the question. We often work with git where the relative path is very convenient
setrelwd <- function(rel_path){
curr_dir <- getwd()
abs_path <- file.path(curr_dir,rel_path)
if(dir.exists(abs_path)){
setwd(abs_path)
}
else
{
warning('Directory does not exist. Please create it first.')
}
}
> setrelwd("Summer2016")
Warning message:
In setrelwd("Summer2016") : Directory does not exist. Please create it first.
Also if you don't want to see the warning message but create a folder right away see Check existence of directory and create if doesn't exist
To make things a bit more portable where I work we all put this in a Rprofile
hdrive=
switch(Sys.info()[[1]],
'Linux'="/mnt/hdrive",
'Windows'="H:/",
"Darwin"="/Volumes/hdrive/mnt/hdrive"
)
So i always have that variable to get me to our shared drive. Then in my script we can write
setwd(paste(hdrive,"/relative/path/",sep="/"))
So that gets us around some of the problems that others are talking about.
I personally added the following code. I use Sys.info() and any() with unique information.
First step is to use Sys.info() and find the unique identifier for your computer.
if(any(Sys.info() == "COMPUTER1")) {
setwd("c:/Users/user1/repos/project/")
}
if(any(Sys.info() == "COMPUTER2")) {
setwd("home/user1/repos/project/")
}
and just add the name of the computer to the if statement and add the correct path. Just add a new if for each machine.
For reproduction it does not change anyone's working directory unless they are that specific user.