running r scripts or commands with interpretor in unix for unix-layman
Assuming you save your script in a simple text file with the name so.R
, you can run it under Linux/Unix by typing R
at the prompt. Once in R enter
source('so.R')
to execute the script inside the R environment (this assumes the so.R file is in the same directory as you are when you issue this command).
To run the script from the Linux/Unix command line use the following command:
R CMD BATCH so.R
Note that I got the plot to show when I ran the script inside of R, but from the Linux command line it doesn't show. I suspect it gets quickly displayed and then goes away, so there will be a R command that you have to look up to make it pause after it displays the plot.
What's the best way to use R scripts on the command line (terminal)?
Content of script.r
:
#!/usr/bin/env Rscript
args = commandArgs(trailingOnly = TRUE)
message(sprintf("Hello %s", args[1L]))
The first line is the shebang line. It’s best practice to use /usr/bin/env Rscript
instead of hard-coding the path to your R installation. Otherwise you risk your script breaking on other computers.
Next, make it executable (on the command line):
chmod +x script.r
Invocation from command line:
./script.r world
# Hello world
Can I start an Rcmdr session from a unix shell?
Working on an Ubuntu machine here, I was able to use the advice provided by Dirk in this mailing list post:
nathan@nathan-laptop:~/tmp$ cat rcommander.r
#!/bin/bash
r -lRcmdr -e'while(TRUE) Commander();'
nathan@nathan-laptop:~/tmp$ cat rcommander2.r
#!/bin/bash
Rscript --default-packages=Rcmdr -e 'while(TRUE) Commander();'
The first script uses Dirk's littler
package, available on CRAN, and the second uses the standard Rscript
executable. As noted, you can kill the process with ctrl + c
from your terminal.
How to run a shell script on a Unix console or Mac terminal?
To run a non-executable sh
script, use:
sh myscript
To run a non-executable bash
script, use:
bash myscript
To start an executable (which is any file with executable permission); you just specify it by its path:
/foo/bar
/bin/bar
./bar
To make a script executable, give it the necessary permission:
chmod +x bar
./bar
When a file is executable, the kernel is responsible for figuring out how to execte it. For non-binaries, this is done by looking at the first line of the file. It should contain a hashbang
:
#! /usr/bin/env bash
The hashbang tells the kernel what program to run (in this case the command /usr/bin/env
is ran with the argument bash
). Then, the script is passed to the program (as second argument) along with all the arguments you gave the script as subsequent arguments.
That means every script that is executable should have a hashbang. If it doesn't, you're not telling the kernel what it is, and therefore the kernel doesn't know what program to use to interprete it. It could be bash
, perl
, python
, sh
, or something else. (In reality, the kernel will often use the user's default shell to interprete the file, which is very dangerous because it might not be the right interpreter at all or it might be able to parse some of it but with subtle behavioural differences such as is the case between sh
and bash
).
A note on /usr/bin/env
Most commonly, you'll see hash bangs like so:
#!/bin/bash
The result is that the kernel will run the program /bin/bash
to interpret the script. Unfortunately, bash
is not always shipped by default, and it is not always available in /bin
. While on Linux machines it usually is, there are a range of other POSIX machines where bash
ships in various locations, such as /usr/xpg/bin/bash
or /usr/local/bin/bash
.
To write a portable bash script, we can therefore not rely on hard-coding the location of the bash
program. POSIX already has a mechanism for dealing with that: PATH
. The idea is that you install your programs in one of the directories that are in PATH
and the system should be able to find your program when you want to run it by name.
Sadly, you cannot just do this:
#!bash
The kernel won't (some might) do a PATH
search for you. There is a program that can do a PATH
search for you, though, it's called env
. Luckily, nearly all systems have an env
program installed in /usr/bin
. So we start env
using a hardcoded path, which then does a PATH
search for bash
and runs it so that it can interpret your script:
#!/usr/bin/env bash
This approach has one downside: According to POSIX, the hashbang can have one argument. In this case, we use bash
as the argument to the env
program. That means we have no space left to pass arguments to bash
. So there's no way to convert something like #!/bin/bash -exu
to this scheme. You'll have to put set -exu
after the hashbang instead.
This approach also has another advantage: Some systems may ship with a /bin/bash
, but the user may not like it, may find it's buggy or outdated, and may have installed his own bash
somewhere else. This is often the case on OS X (Macs) where Apple ships an outdated /bin/bash
and users install an up-to-date /usr/local/bin/bash
using something like Homebrew. When you use the env
approach which does a PATH
search, you take the user's preference into account and use his preferred bash over the one his system shipped with.
Run R script from command line
If you want the output to print to the terminal it is best to use Rscript
Rscript a.R
Note that when using R CMD BATCH a.R
that instead of redirecting output to standard out and displaying on the terminal a new file called a.Rout will be created.
R CMD BATCH a.R
# Check the output
cat a.Rout
One other thing to note about using Rscript is that it doesn't load the methods
package by default which can cause confusion. So if you're relying on anything that methods provides you'll want to load it explicitly in your script.
If you really want to use the ./a.R
way of calling the script you could add an appropriate #!
to the top of the script
#!/usr/bin/env Rscript
sayHello <- function(){
print('hello')
}
sayHello()
I will also note that if you're running on a *unix system there is the useful littler package which provides easy command line piping to R. It may be necessary to use littler to run shiny apps via a script? Further details can be found in this question.
How can I avoid having my R script printed every time I run it?
Resolution is to run with Rscript, and not with R. Examples elsewhere (e.g. How can I read command line parameters from an R script?), run scripts from the command line with
R --args args1 args2... < foo.R
running with
Rscript foo.R args1 args2 ...
produces only the output, and not the script. It's also a much cleaner way to run scripts.
Executing Unix shell scripts in talend open studio for big data
Yes you can execute the shell scripts on your unix server using Talend Studio for Data Integration. The component to use is tSystem which can call shell scripts.
Check below help links for demo with tSystem component
https://help.talend.com/display/KB/Executing+a+command+with+spaces+using+a+tSystem+component
http://www.vikramtakkar.com/2013/04/tsystem-how-to-execute-unix-or-linux.html
There is no need of separate Unix installer. Just call the specific Unix file like "TOS_DI-linux-gtk-x86.sh" to launch the studio on Unix Machine. You can find this file in installation root.
What is the cleanest way to ssh and run multiple commands in Bash?
How about a Bash Here Document:
ssh otherhost << EOF
ls some_folder;
./someaction.sh 'some params'
pwd
./some_other_action 'other params'
EOF
To avoid the problems mentioned by @Globalz in the comments, you may be able to (depending what you're doing on the remote site) get away with replacing the first line with
ssh otherhost /bin/bash << EOF
Note that you can do variable substitution in the Here document, but you may have to deal with quoting issues. For instance, if you quote the "limit string" (ie. EOF
in the above), then you can't do variable substitutions. But without quoting the limit string, variables are substituted. For example, if you have defined $NAME
above in your shell script, you could do
ssh otherhost /bin/bash << EOF
touch "/tmp/${NAME}"
EOF
and it would create a file on the destination otherhost
with the name of whatever you'd assigned to $NAME
. Other rules about shell script quoting also apply, but are too complicated to go into here.
R scripting and command-line front-end
Are you really running that from the unix shell prompt? Because I can get something like that error by typing that command at the R prompt:
$ R
[startup noises]
> Rscript foo.r
Error: unexpected symbol in "Rscript foo.r"
Otherwise its something in your script that is similarly screwed up.
When run from the Unix command prompt, all is well:
$ Rscript test.R
[1] 1.414214
where test.R
is simply print(sqrt(2))
Related Topics
Change Filenames to Lowercase in Ubuntu in All Subdirectories
How to Read a Sector Using a Bio Request in Linux Kernel
When and How Are System Calls Interrupted
How to Find Which Process Is Leaking Memory
Custom Git Command Autocompletion
How to Add a String to the Beginning of Each File in a Folder in Bash
Checkpoint/Restart Using Core Dump in Linux
"Tput: No Value for $Term and No -T Specified " Error Logged by Cron Process
X86_64 Linux Syscall Arguments
Sed: How to Delete Lines Matching a Pattern That Contains Forward Slashes
Linux: Create Random Directory/File Hierarchy
Compile Programs on Multicore or Distributed System
Run Docker in Ubuntu Live Disk
How to Use Aio and Epoll Together in a Single Event Loop
Grep Search All Files in Directory for String1 and String2
Accessing Linux /Dev/Usb as Standard Files to Communicate with Usb Device
How to Flush Cache of Hard-Disk and Flash-Disk (Or Filesystem) from Command Line