I would like my .cshrc file to carry out several commands depending on the host I've logged in to (the .cshrc file is on a disk that is shared by two different hosts).
Let's assume the two hosts are: login1.university.edu and login2.university.edu
I tried this command:
if(hostname == 'login1.university.edu') then
setenv R_LIBS_USER /n/Users/me/R.login1
else
setenv R_LIBS_USER /n/Users/me/R.login2
endif
which doesn't work.
What is the correct syntax?
Surround the hostname command with backtics to execute it and compare the result.
if(`hostname` == 'login1.university.edu') then
setenv R_LIBS_USER /n/Users/me/R.login1
else
Related
I'm currently struggling with running a .sh script I'm trying to trigger from Jenkins.
Within the Jenkins "execute shell" section, I'm connecting to a remote server (The Jenkins agent does not have right OS to build what I need.), using:
cp -r . /to/shared/drive/to/have/access/on/remote
ssh -t -t username#servername << EOF
cd /to/shared/drive/to/have/access/on/remote
source build.sh dev
exit
EOF
Inside build.sh, I'm exporting R_LIBS to build a package for different R versions.
...
for path in "${!rVersionPaths[#]}"; do
export R_LIBS="${path}"
Rscript -e 'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'
...
Setting R_LIBS should functions here like setting lib within install.packages(...). For some reason the R_LIBS export doesn't get picked up. Also setting other env variables like http_proxy are ignored. This causes any requests outside the network to fail.
Is there any particular way of achieving this?
Maybe pass those variables with env, like
env R_LIBS="${path}" Rscript -e 'install.packages(c("someDependency", .....
Well i'm not able to comment on the question, so posting it as answer.
I had similar problem when calling remote shell script from Jenkins, the problem was somehow bash_profile variables were not loaded when called the script from Jenkins but locally it worked. Loading the bash profile in ssh connection solved it for me.
Add source to bash_profile in build.sh
. ~/.bash_profile OR source ~/.bash_profile
Or
Reload bash_profile in ssh connection
`ssh -t -t username#servername << EOF
. ~/.bash_profile
your commands here
exit
EOF
You can set that variable in the same command line like this:
R_LIBS="${path}" Rscript -e \
'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'
It's possible to append more variables in this way. Note that this will set those environment variables only for the command being called after them (and its children processes as well).
You said that "R_LIBS export doesn't get picked up". Question Is the value UNSET? Or is it set to some other value & you are trying to override it?
It is possible that SSH may be invoking "/bin/sh -c". Based on the second answer to: Why does 'cd' command not work via SSH?, you can simplify the SSH command and explicitly invoke the build.sh script in Bash:
cp -r . /to/shared/drive/to/have/access/on/remote
ssh -t -t username#servername "cd /to/shared/drive/to/have/access/on/remote && bash -f build.sh dev"
This makes the SSH invocation more similar to invoking the command within a remote interactive shell. (You can avoid sourcing scripts and exporting variables.)
You don't need to export R_LIBSor env R_LIBS when it is possible to prefix any command with local environment variable overrides (agrees with Luis' answer):
...
for path in "${!rVersionPaths[#]}"; do
R_LIBS="${path}" Rscript -e 'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'
...
The Rscript may be doing a lot with env vars. You can verify that you are setting the R_LIBS env var by replacing Rscript with the env command and observe the output:
...
for path in "${!rVersionPaths[#]}"; do
R_LIBS="${path}" env
...
According to this manual "Initialization at Start of an R Session", Rscript looks in several places to load "site and user files":
$R_PROFILE
$R_HOME/etc/Renviron
$R_HOME/etc/Renviron.site
$R_ENVIRON_USER
$R_PROFILE_USER
./.Rprofile
$HOME/.Rprofile
./.RData
The "Examples" section of that manual shows this:
## Not run:
## Example ~/.Renviron on Unix
R_LIBS=~/R/library
PAGER=/usr/local/bin/less
If you add the --vanilla command-line option to ignore all of these files, then you may get different results and know something in the site/init/environ files is affecting your R_LIBS! I cannot run this system myself. Hopefully we have given you some areas to investigate.
You probably don't want to source build.sh, just invoke it directly (i.e. remove the source command).
By source-ing the file your script is executed in the SSH shell (likely sh) rather than by bash, which it sounds like is what you intended.
When I start tmux, my ~/.config/fish/config.fish seems to be sourced again. This means any set PATH foo $PATH statements in my config get executed again, which leads to my PATH variable having duplicate entries in it. This isn't drastic, but it is annoying to ECHO path. when it is so long
How can I prevent this problem?
EDIT: the only fish related entires in my tmux file are
#fix vim
set -g default-shell $SHELL
set -g default-command "reattach-to-user-namespace -l ${SHELL}"
set -g default-command 'reattach-to-user-namespace $SHELL --login'
The ~/.config/fish/config.fish config file is read by every new fish instance. There are several ways to achieve what you're asking. One option is to always set PATH from scratch. That is, don't modify the existing path by appending or prepending to it but instead set it to exactly what you want for a given machine. Something along the lines of
set -gx PATH $HOME/bin /usr/local/bin /usr/bin/ /bin
test -d /opt/X11/bin
and set PATH $PATH /opt/X11/bin
Another option is to add directories only if they aren't already in the path:
contains /usr/local/bin $PATH
or set PATH /usr/local/bin $PATH
Or only do the modification if not inside a tmux session:
if not set -q TMUX
set PATH /argle/bargle $PATH
end
I use global aliases for some of my remote hosts like
alias -g MY_HOST="server.waytolongfoobar.com" to be able to ssh into them using ssh MY_HOST. But if I want to scp something to the host, I have to use something awkward like scp file.tar.gz 'echo MY_HOST':~/dir. Is there a nicer way to use global aliases inside arguments?
Maybe I use global aliases for the wrong purpose? I think I could actually use exported variables like scp file $MY_HOST:~/dir. What's the benefit of global aliases over variables anyway (beside not having to type the $).
You can define host aliases directly in ssh without using the shell. Add the following to your .ssh/config file:
host MY_HOST
HostName server.waytolongfoobar.com
Now, any place where ssh or scp would take a host name, it will treat MY_HOST as a synonym for server.waytolongfoobar.com.
As to your question regarding the utility of aliases, they are expanded before any part of the command line is parsed, allowing you to include shell syntax:
% alias -g PAGE="| less"
% cat .zshrc PAGE # expands to cat .zshrc | less
% alias -g ignore="> /dev/null"
% cat .zshrc ignore
In your case, there is no good way to use an alias because it has to be an independent (space separated) token on the command line. Aliases can actually be less flexible than variables for that exact reason. The purpose of an alias is to save you typing. Global aliases are intended for files or other standalone expressions that you use very frequently. A host name is generally not standalone.
Is there a way (in UNIX) to trace how my $PATH is set?
I have an entry in my path that I don't want, but I just can't find the source to remove it for good. I am running Solaris 10 and CSH.
It is set in /home/<your_user>/.profile or /home/<your_user>/.bash_profile.
Check it doing
grep -l PATH /home/<your_user>/.* 2>/dev/null
that will point the .files that are defining this variable.
I can't seem to set a new $PATH such that it is used when executing commands via ssh user#host command. I have tried adding export PATH=$PATH:$HOME/new_path to ~/.bashrc and ~/.profile on the remote machine, but executing ssh user#host "echo \$PATH" shows that the change has not been picked up (it shows /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games). The remote machine is running Ubuntu 8.04.
I'm sure I could hack it into /etc/profile, but that's not a clean solution and it only works when one has root access.
As grawity said, ~/.bashrc is what you want, since it is sourced by non-interactive non-login shells.
I expect the problem you're having has to do with the default Ubuntu ~/.bashrc file. It usually starts with something like this:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
You want to put anything for non-interactive shells before this line.
Do you have an ~/.bash_login or ~/.bash_profile?
Bash in interactive mode checks for these files, and uses the first existing one, in this order:
~/.bash_profile
~/.bash_login
~/.profile
So if you have an ~/.bash_profile, then whatever changes you do to ~/.profile will be left unseen.
Bash in non-interactive mode sometimes reads the file ~/.bashrc (which is also often source'd from the interactive scripts.) By "sometimes" I mean that it is distribution-dependent: quite oddly, there is a compile-time option for enabling this. Debian enables the ~/.bashrc reading, while e.g. Arch does not.
ssh seems to be using the non-interactive mode, so ~/.bashrc should be enough. When having problems like this, I usually add a few echo's to see what files are being run.
ssh documentation says:
If command is specified, it is executed on the remote host instead of a login shell.
which is why adding to the bashrc files doesn't work. you do however have the following options:
If the PermitUserEnvironment option is set in the sshd config, you can add your PATH setting to ~/.ssh/environment
ssh remotemachine 'bash -l -c "somecommand"'
You can always say:
ssh remotemachine 'export PATH=wedontneedastinkingpath; echo $PATH'
In addition to #signpolyma answer, you will have to add your export before these lines
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Just had the same problem myself, solved it with:
ssh user#remotehost PATH=\$HOME/bin:\$PATH\; remote-command