Running R Scripts or Commands with Interpretor in Unix for Unix-Layman

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



Leave a reply



Submit