How to set R environment in /etc/profile? - r

my os is debian6,there is a libR.pc after i compile to install R
root#debian:/home/tiger# cat /home/tiger/R-2.15.1/lib/pkgconfig/libR.pc
rhome=/home/tiger/R-2.15.1/lib/R
rlibdir=${rhome}/lib
rincludedir=/home/tiger/R-2.15.1/lib/R/include
Name: libR
Description: R as a library
Version: 2.15.1
Libs: -L${rlibdir} -lR
Cflags: -I${rincludedir} -I${rincludedir}
Libs.private:
when set R environment in /etc/profile:
R_HOME= /home/tiger/R-2.15.1
or
R_HOME= /home/tiger/R-2.15.1/lib/R
which line will i choose to write in /etc/profile?

On a Debian (or derivative such as Ubuntu system) you have /etc/R/ to set variable which R uses:
edd#max:~$ ls -l /etc/R/
total 28
-rw-r--r-- 1 root root 602 Jun 17 20:29 ldpaths
-rw-r--r-- 1 root root 5461 Jun 17 20:29 Makeconf
-rw-r--r-- 1 root root 1868 Mar 31 13:50 Renviron
-rw-r--r-- 1 root root 608 Sep 25 2009 Renviron.site
-rw-r--r-- 1 root root 1159 Mar 31 08:03 repositories
-rw-r--r-- 1 root root 792 Oct 28 2009 Rprofile.site
edd#max:~$
and the files in R_HOME/etc/ should be softlinks --- at least if you use the prebuilt binaries. If you build you own binaries, it's your problem.
The file you quote is installed as /usr/lib/pkgconfig/libR.pc on a Debian / Ubuntu system. Setting R_HOME is not needed as R finds its own values (see #flodel's answer).

On my system:
cat $R_HOME
gives nothing, but inside an R session, I get:
> Sys.getenv("R_HOME")
[1] "/usr/lib/R"
This should tell you two things:
that R_HOME is set at R's startup, so unless you know exactly what you are doing, maybe you don't need to set it up in your /etc/profile.
you can use Sys.getenv to find out the exact path to your R_HOME.

Related

WSL2, Launching R console from Docker

I've started to play with R, and wanted to build a simple custom image. When attempting to launch a new container with the r-base official image, using the instructions provided, it fails.
$ docker run -ti --rm r-base
ERROR: R_HOME ('/usr/lib/R') not found
I'm running Debian 10, on WSL2:
$ uname -r
5.4.72-microsoft-standard-WSL2
$ lsb_release -a
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
$ docker --version
Docker version 18.09.1, build 4c52b90
Launching a container with bash, there are files in the mentioned lib directory:
$ docker run -ti --rm r-base /bin/bash
root#f27f0139a6be:/# ls -l /usr/lib/R/
total 28
drwxr-xr-x 3 root root 4096 Jul 12 13:23 bin
lrwxrwxrwx 1 root root 33 Jun 23 10:26 COPYING -> ../../share/common-licenses/GPL-2
drwxr-xr-x 2 root root 4096 Jul 12 13:23 etc
drwxr-xr-x 2 root root 4096 Jul 12 13:23 lib
drwxr-xr-x 32 root root 4096 Jul 12 13:23 library
drwxr-xr-x 2 root root 4096 Jul 12 13:23 modules
drwxr-xr-x 4 root root 4096 Jul 12 13:23 site-library
-rw-r--r-- 1 root root 46 Jun 23 10:26 SVN-REVISION
root#f27f0139a6be:/# R
ERROR: R_HOME ('/usr/lib/R') not found
I've played around with a few different recent tags/versions of the image, but same issue. Is this some incompatibility with WSL2? Am I missing an environment variable?

Difference in behavior between 2 aliased cds in unix shell

I connect to a remote computer thru VNC and use Konsole for my work. Konsole is version 2.3.3 using KDE 4.3.4. I have these two aliases:
alias ll 'ls -haltr; pwd'
alias cd 'cd \!*; ll'
which I observed to have the following behavior:
When path exists, it will cd to it and also do the ll alias
When path doesn't exist, it will simply say the path doesn't exist and won't do the ll anymore
Example:
Path exists
[10] % cd foo
total 14K
-rw-r----- 1 user group 913 Jun 3 2014 readme
-rw-r----- 1 user group 1.2K Dec 3 2020 report.txt
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user/foo
[11] %
Path doesn't exist
[10] % cd nowhere
nowhere: No such file or directory.
[11] %
Now our department has transferred to another division and we've just started to connect remotely thru Exceed TurboX. I still use Konsole but the version is now 2.10.5 using KDE 4.10.5. I copied over the same two aliases, but I'm now observing a different behavior:
When path exists, it will cd to it and also do the ll alias (basically same as #1 above)
When path doesn't exist, it will attempt to cd AND still do the ll (different as #2 above)
So for #2, here's how it looks like:
[10] % cd nowhere
nowhere: No such file or directory.
total 120K
-rw-r----- 1 user group 272 Jan 6 2021 .cshrc
-rw-r----- 1 user group 1.2K Jan 6 2021 .alias
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user
[11] %
I would like to know how to get behavior #2 of the previous working environment to this current working environment.
I've added the information on the Konsole and KDE versions because if the behavior is due to the version and there's no workaround, then I'll just be sad for the rest of my life working in this new remote desktop env. ^_^
I'm currently exploring a "check first if the path exists before doing ll" but to no avail. :'(
Edit:
The shell I'm using is tcsh
% printenv SHELL in both environments showed /bin/tcsh
And in addition:
Old environment
% echo $version
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec
New environment
% echo $version
3
The information in the question is still not sufficient to find out why tcsh behaves differently in the two working environments.
The alias defines a sequence of commands (cd followed by ll) without any condition.
alias cd 'cd \!*; ll'
On one system the execution of the alias seems to stop if the cd command reports an error for currently unknown reasons.
The correct way to prevent the execution of ll after a failed cd command would be the conditional execution of the ll command, e.g.
alias cd 'cd \!* && ll'
The decade long advice is: do not use aliases, use functions.
ll() { ls -haltr "$#" && pwd; }
cd() { cd "$#" && ll; }

R package builds & pkgbuild::compile_dll failing; New files in /tmp are not executable

I'm attempting to build a package and install R packages that use Rccp. These are failing because files in /tmp are not executable.
These problems arose after switching to a new Dell xps 13 pre-installed with Ubuntu 18.04. For the build, I've been using pkgbuild::compile_dll to compile some C code with Rccp. I only found out about the problem installing new packages while troubleshooting the problem with compile_dll. This confirmed that its not a problem with pkgbuild.
Here is the error message from compile_dll:
> pkgbuild::compile_dll()
Registered S3 methods overwritten by 'ggplot2':
method from
[.quosures rlang
c.quosures rlang
print.quosures rlang
Re-compiling spstan
─ installing *source* package ‘spstan’ ...
** using staged installation
ERROR: 'configure' exists but is not executable -- see the 'R
Installation and Administration Manual'
─ removing
‘/home/connor/tmp/RtmpC0EMxX/devtools_install_570e38f2a7e3/spstan’
Error in (function (command = NULL, args = character(),
error_on_status = TRUE, :
System command error
There's plenty of help out there for this it seems, except that none of the solutions are working for me. Here is what I've tried.
Remount /tmp as in
https://github.com/r-lib/devtools/issues/32
Remount /tmp and enable executable files be entering the following in the terminal:
sudo mount -o remount,exec /tmp
Which gives the following error message: mount point not mounted or bad option. Since /tmp isn't mounted separately on my computer, its part of the root filesystem, the above solution fails because /tmp can't be remounted.
Following the instructions from the R Installation and Administration Manual, make sure TMPDIR points to some temporary file system in which scripts are allowed to be executed. So I made a new tmp folder called ~/Rtmp and mounted it:
mkdir ~/Rtmp
mount -t tmpfs -o exec ~/Rtmp
Also adding the following line to my ~/.Renviron file:
TMPDIR=/home/connor/Rtmp
and adding the following line to /etc/fstab:
tmpfs /home/connor/Rtmp tmpfs exec 0 0
and then rebooting the computer before running pkgbuild::compile_dll() again. I get the same error message but I could confirm that R was using /Rtmp folder I directed it to.
Following some advice here https://ubuntuforums.org/showthread.php?t=2421441 change permissions on the /tmp folder recursively with
sudo chmod -R 777 ~/tmp
This also fails. The problem seems to be that compile_dll is creating a new script that it wants to run and the permissions on the folder aren't the default for new files that get added to it.
When I print out the permissions for /tmp, the script that is failing with compile_dll is listed without the same permissions as all the older files:
drwx------ 3 connor connor 4096 Jun 23 15:20 RtmpC0EMxX
drwxrwxrwx 9 root root 4096 Jun 23 09:53 RtmpGb3QiA
drwxrwxrwx 3 connor connor 4096 Jun 23 10:44 RtmpI9hu1U
drwxrwxrwx 2 connor connor 4096 Jun 23 10:41 RtmpIgi5su
drwxrwxrwx 2 connor connor 4096 Jun 23 10:07 RtmpK4p4Od
drwxrwxrwx 4 root root 4096 Jun 23 09:17 RtmppdbqeT
drwxrwxrwx 10 root root 4096 Jun 23 09:54 RtmpR4Cc9c
drwxrwxrwx 14 root root 4096 Jun 23 10:13 Rtmpuweyxz
drwxrwxrwx 2 connor connor 4096 Jun 23 10:07 RtmpwN9SbT
drwxrwxrwx 2 connor connor 4096 Jun 23 10:04 RtmpY7g0NK
So I'm still stuck. Am I doing something wrong here? Or do I need to start looking somewhere else for the source of the problem?

How to use `ln -s` to change between R Versions on Mac?

An RStudio support article says that you can alternate between different R Versions on your mac if you "update the R.framework/Versions/Current directory alias directly using ln -s"
How exactly do you use ln -s to change between R Versions?
When I type into my terminal ls -l /Library/Frameworks/R.framework/Versions/ I see:
total 0
drwxrwxr-x 6 root admin 192 Jan 15 09:04 3.3
drwxrwxr-x 6 root admin 192 Jun 5 16:36 3.5
drwxrwxr-x 3 root admin 96 Jun 5 16:36 3.6
lrwxr-xr-x 1 root admin 3 Jun 5 16:36 Current -> 3.5
But I am unsure of how ln -s can be used to alternate between these R versions. I have currently "switched" from 3.6 to 3.5 by redownloading 3.5. A practice I would like to avoid.
Into my terminal I typed rm /Library/Frameworks/R.framework/Versions/Current which did remove the existing Current. And then on separate attempts I have typed ln -s 3.6 /Library/Frameworks/R.framework/Versions/Current
This changed the symlink
ls -l /Library/Frameworks/R.framework/Versions/
total 0
drwxrwxr-x 6 root admin 192 Jan 15 09:04 3.3
drwxrwxr-x 6 root admin 192 Jun 5 16:36 3.5
drwxrwxr-x 4 root admin 128 Jun 6 09:09 3.6
lrwxr-xr-x 1 joepowers admin 3 Jun 6 09:15 Current -> 3.6
But when I type R.version in the console I get back 3.4.3
Next I tried
ln -s /Library/Frameworks/R.framework/Versions/3.6 /Library/Frameworks/R.framework/Versions/Current
ls -l /Library/Frameworks/R.framework/Versions/
total 0
drwxrwxr-x 6 root admin 192 Jan 15 09:04 3.3
drwxrwxr-x 3 root admin 96 Jun 6 09:21 3.5
drwxrwxr-x 7 root admin 224 Jun 6 09:21 3.6
lrwxr-xr-x 1 joepowers admin 44 Jun 6 09:23 Current -> /Library/Frameworks/R.framework/Versions/3.6
But typing R.version in the console still returns 3.4.3 even after restarting RStudio.
ln -s creates a symlink, also known as an alias (on Mac) or shortcut (in Windows).
When it starts R, RStudio loads the version of R in /Library/Frameworks/R.framework/Versions/Current.
From that view you posted above, we can see that you have 3 versions of R installed (3.3, 3.5, and 3.6). /Current is actually a symlink to 3.5 (that's what the Current -> 3.5 means).
If you want to change this, you need to:
Go to the appropriate directory with: cd /Library/Frameworks/R.framework/Versions/
Delete the existing Current symlink with: rm Current
rm will delete symlinks to directories but will not delete directories themselves
Create a new symlink to version 3.6 with: ln -s 3.6 Current

Unable to extract tar file - tar: extract not authorized

I am working on Solaris 10 machine. In that i cannot able to untar my file. Logs are given below. Anyone please suggest what may be the issue? I can able to create tar file but unable to untar. :(
bash-3.2# ls -lrth ConfigCheck-120614-KL.out*
-rw-r--r-- 1 root root 144K Jun 12 17:15 ConfigCheck-120614-KL.out
-rwxrwxrwx 1 root root 146K Jun 16 16:49 ConfigCheck-120614-KL.out.tar
bash-3.2# tar xvf ConfigCheck-120614-KL.out.tar
tar: extract not authorized
bash-3.2# tar tvf ConfigCheck-120614-KL.out.tar
-rw-r--r-- 0/0 147377 Jun 12 17:15 2014 ConfigCheck-120614-KL.out
Solaris 11 tar will fail with that error message if you are running as uid 0 but do not have the Media Restore profile set up in the RBAC configuration.
Unless you're trying to restore from backup, you should normally be untarring files as a normal user, not root, to avoid accidentally overwriting critical system files.

Resources