I tried to run a Python script from R with:
system('python script.py arg1 arg2')
And got an error:
ImportError: No module named pandas
This was a bit of a surprise since the script was working from the terminal as expected. Having encountered this type of issue before (with knitr, whence the engine.path chunk option), I know to check:
Sys.which('python')
# python
# "/usr/bin/python"
And compare it to the command line:
$ which python
# /Users/michael.chirico/anaconda2/bin/python
(i.e., the error arises because I have pandas installed for the anaconda distribution, though TBH I don't know why I have a different distribution)
Hence I can fix my issue by running:
system('/Users/michael.chirico/anaconda2/bin/python script.py arg1 arg2')
My question is two-fold:
How does R's system/Sys.which find a different python than my terminal?
How can I fix this besides writing out the full binary path each time?
I read ?Sys.which for some hints, but to no avail. In particular, ?Sys.which suggests Sys.which is using which:
This is an interface to the system command which
This is clearly (?) untrue; to be sure, I checked Sys.which('which') and which which to confirm both are pointing to /usr/bin/which (goaded on by this tidbit):
On a Unix-alike the full path to which (usually /usr/bin/which) is found when R is installed.
To the latter, on a whim I tried Sys.setenv(python = '/Users/michael.chirico/anaconda2/bin/python') to no avail.
As some of the comments hint, this is a problem that arises because the PATH environment variable is different for programs launched by Finder (or the Dock) than it is in the Terminal. There are ways to set the PATH for Dock-launched applications, but they aren't pretty. Here's a place to start looking if you want to go that route:
https://apple.stackexchange.com/questions/51677/how-to-set-path-for-finder-launched-applications
The other thing you can do, which is probably more straightforward, is tell R to set the PATH variable when it starts up, using Sys.setenv to add the path to your desired Python instance. You can do that for just one project, for your whole user account, or for the whole system, by placing the command in a .Rprofile file in the corresponding location. More information on how to do this here:
https://stat.ethz.ch/R-manual/R-devel/library/base/html/Startup.html
Related
rmarkdown::find_pandoc helps us to find the pandoc executable w/o the need of specifiying any environmental variable when running form within RStudio:
## in Rstudio
!is.null(rmarkdown::find_pandoc()$dir)
# [1] TRUE
However, when running the same command from a plain R console I get:
### R console
!is.null(rmarkdown::find_pandoc()$dir)
# [1] FALSE
Reading the documentation pf ?rmarkdown::find_pandoc(), explains why I am getting these results:
dir: A character vector of potential directory paths under which
‘pandoc’ may be found. If not provided, this function
searches for ‘pandoc’ from the environment variable
RSTUDIO_PANDOC (the RStudio IDE will set this variable to the
directory of Pandoc bundled with the IDE), the environment
variable PATH, and the directory ‘~/opt/pandoc/’.
I want now to write a script which can be run from the command line (specifically not from within RStudio), which needs pandoc to be found. As per the help I could set my PATH to assure that pandoc is also found from the command line, but as soon as I want a colleague of mine to use the script, I have to make sure that his/her PATH is set accordingly and I want to avoid that.
However, I do know that everybody has Rstudio installed (not at the same location though), so if I knew the location of RStudio I could derive pandoc's location too.
Is there any reliable way to get the path of Rstudio from the console (i.e. also when Rstudio is not running)?
To make a long story short: how can I find Rstudio even if it is not running`?
This could work, it is based on linux, but I guess if you are in other system, it could be adapted:
pandoc_path <- system2("find", args="/usr/lib/rstudio -name pandoc -type f", stdout = T)
path_sep <- ":"
Sys.setenv(PATH = paste0(Sys.getenv("PATH"),path_sep, sub(".pandoc$","",pandoc_path )))
I am trying to install Julia on Atom. What I made already is that I installed Julia in this folder :
E:\Program files\Users\Zeedo\AppData\Local\Julia-0.6.3
and I installed Atom. Then, I also installed language-Julia package.
Now, when I want to run a code, I get this error:
Julia could not be started.
We tried to launch Julia from:
julia
This path can be changed in the settings.
Details:
'"julia"' is not recognized as an internal or external command,
operable program or batch file.
So, I don't know where should I give the Julia address to the Atom.Or, if you know something that I am doing wrong, please let me know.
Thanks :)
Atom cannot run code by default, so that error message must be being thrown by a community package you've installed. Searching shows me the package is most likely atom-julia-client. And the error seems to be because it can't find the Julia binary it needs to run the program.
First, you should make sure you can run the julia command from the command line directly, which you can check by running julia --version. If this doesn't work, then you need to add the Julia binary to your path.
If the above didn't work, try go to Settings -> Packages -> julia-client. In here, the first setting is Julia Path, which is defaulted to julia (like in the error). Change this to an absolute path, directly to the binary (or to the folder containing the binary; try both if the first doesn't work).
FYI, the language-julia package just gives you syntax highlighting and snippets, and doesn't actually need any Julia stuff to work.
So I tried adding R to the path on windows 10 (that is supposedly easy).
System Properties -> Environment variables -> Edit -> new: copy and paste: "C:\Program Files\R\R-3.5.0\bin\x64"
Now the thing is, Powershell just refuses to start the R environment when I type in R. R.exe works apparently. Rgui works as well. Is R a reserved letter in powershell or something? It also seems to repeat the previous command sometimes but that doesn't really seem completely consistent either.
(I put this entry on top of the list of the path and restarted the pc already)
when entering get-alias r I got the following result, so yes "r" is already taken ...
CommandType Name Version Source
----------- ---- ------- ------
Alias r -> Invoke-History
PS: you could remove that alias with remove-item alias:\r from your current powershell session and test if "r" then starts "R.exe". if that works for you, you could edit your profile to remove the alias "r -> Invoke-History" from every new session.
To generalize Guenther Schmitz' helpful answer:
PowerShell has several types of commands, whose precedence is:
Alias
Function
Cmdlet
External application
Note that name resolution is always case-insensitive, so that both r and R refer to the same command.
That is, before R resolves to R.exe, it is not only an r alias that could get in the way, but potentially also a function or a cmdlet (though the latter case is hypothetical, because well-behaved cmdlets follow a <Verb>-<Noun> naming pattern).
Note that built-in aliases shadowing external programs, especially standard ones, is problematic, and in the context of PowerShell Core a discussion is underway about whether to remove all built-in aliases and make them opt-in only - see this GitHub issue.
To see what a given name resolves to, use the Get-Command cmdlet:
# See what R resolves to
Get-Command R
# See ALL commands that R *can* resolve to, with the EFFECTIVE one listed first:
Get-Command -All R
Choices for unambiguously targeting R.exe:
(As you already know) If its folder is in one of the folders listed in environment variable $env:PATH, append .exe - i.e., use the filename extension explicitly:
R.exe ...
Use R.exe's full path (note the need for & for invocation, because the path needs quoting):
& "C:\Program Files\R\R-3.5.0\bin\x64\R.exe" ...
(For the sake of completeness; this is the cumbersome equivalent of using just R.exe): Use Get-Command -Type Application to locate the executable:
& (Get-Command -Type Application R) ...
Alternatively, as stated in Guenther's answer, you could add Remove-Alias r to your PowerShell $PROFILE file in order to remove the built-in alias on session startup, which then allows you to just use r to start R.exe.
Run the following code in your console to install the R package. This code will automatically add R to your os PATH.
sudo apt-get install littler
I cannot run a R session from the command line by typing 'R', despite having
C:/Program Files/R
and
C:/Program Files/R/R-3.3.2/bin
in both 'Path' (System) and 'PATH' (User) environment variables (the latter directory is where the actual application is located, I was just trying everything by adding the former).
If I manually change the working directory to C:/Program Files/R/R-3.3.2/bin and type R, a session runs.
Any insight as to why this might be the case? Other programs such as Python 3 run fine, provided the the environment variable is set, why not with R?
This question is part of a larger problem where I am trying to get rpy2 working, but though successfully installed, none of it's basic functions are working, and I thought this maybe to do with a version of R being installed at C:/Users/Anaconda2/R (Because this dir was in Path). The R application installed here would not work when opened, but was the directory returned when I typed R RHOME into cmd - despite the fact this installation is not even functioning, and has apparently only existed since I installed rpy2 a couple of hours ago. I reasoned that rpy2 is trying to use the instance of R installed here rather than my normal one, thus causing the error when I call robjects.r. But this still doesn't explain why I can't run R from cmd. When using R.home(component = "home") from inside a an R session (in RStudio or out of it), it returns my normal, working R directory, at C:/PROGRA~1/R/R-33~1.2. By moving the R file tree installed in Anaconda's directory to a somewhere not in Path, I hoped Windows would find the correct installation via Path - but instead I just get Failed to create process.
My last guess was that Windows didn't like the space in "Program Files", but loads of variables in Path go through the same folder. Any ideas?
I am using:
Windows 10,
R 3.3.2,
Python 2.17.13
UPDATE, PERHAPS SOLVED:
On Josh O'Brien's recommendation (thanks!), I typed where R into cmd, returning:
C:\Users\charl\Anaconda2\Scripts\R.exe
C:\Program Files\R\R-3.3.2\bin\R.exe
The first path is marginally different from the C:\Users\charl\Anaconda2\R listed in my first post (both are in Path), and leads to a third R.exe. It's outside the R file tree located in Anaconda, unlike my standard R installation, but seems to be dependent on it nonetheless. If I remove this R.exe to another location (not in Path), Typing R in cmd will run R from the desired directory, thus fixing the problem. R.home() from inside that session confirms this.
My only remaining concern then; is whether this installation of R in Anaconda necessary for rpy2 or can I just delete it, fixing the original problem? It may just be my ignorance, but I was not conscious that installing rpy2 (I used the standard Windows installer rather than compiling manually) would install another instance of R - is it necessary for the package or just a default/option I failed to omit?
How does R's built-in system() function know where to look to invoke some arbitrary OS command specified by the command argument? For example, if I homebrew install some_command_line_program, how does R's system() function know where it is located when I type:
cmd <- "some_complicated_code_from_some_command_line_program"
system(cmd, wait=FALSE)
In other words, how is R smart enough to know where to look without any user input? If I compile from source via Github (instead of homebrew install), would system() also recognize the command?
What system does depends on your OS, you've not told us (although you've given us some clues...).
On unix-alike systems, it executes it as a command in a bash shell, which searches for the first match in the directories on the $PATH environment variable. You can see what that is in R:
> Sys.getenv("PATH")
[1] "/usr/local/heroku/bin:/usr/local/heroku/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/nobackup/rowlings/NEST4B"
In Windows, it does something else.
You can get a full path to whatever it might run with Sys.which, which uses the systems' which command on unixes and fakes it on Windows. Read the help for more.
If you compile something from source then it will be found if the file that runs the command (a shell script, an executable, a #!-script in any language) is placed in a folder in your $PATH. You can create a folder yourself, say /home/user/bin, put your executables in there, add that to your $PATH, and (possibly after logging out an in again, or restarting R, or just firing up a new shell...) then R will find it.