I have multiple scripts naming R001.r, R002.r, and so on. I need to schedule them so that they run in a sequential manner one after the other. What would be the best approach to do this.
I think you want to wrap your r scripts in a caller sh file and then invoke it through terminal. Here is what I would do.
Open up a terminal or any text editor available and fill it up with the following commands:
Rscript R0001.r
Rscript R0002.r
Rscript R0003.r
...
Save this file into something like call_my_scripts. You can then execute it via standard unix shell commands as follows:
./call_my_scripts
This will run sequentially by definition. Make sure you give exec permissions to the file before you invoke it as follows:
chmod u+x call_my_scripts
Related
I have R generating some .csv files for another python program to run in another folder, I know it is possible to call bash from R but how could I call the command make in my ubuntu virtual machine in another directory?
The simple way is creating an script to cd to your dir and exec make after that
script <- tempfile()
fhandle <- file(script)
writeLines("( cd /your_directory && make )",con=fhandle)
system2("/bin/bash",args=c(script))
You may need to find the correct path to /bin/bash, mine is from MacOs
You can work with system2 parameters to control what happens with output from make command and if you want to run the process in parallel with your R task or wait for completion.
I am running a script that starts as follows:
#!/usr/bin/env Rscript
#./geneiase -t static -i mydata.tab
If I run the script on my data directly in the command line, it starts without errors or warnings.
But the program is very demanding computationally so I need to submit my jobs to a cluster using a job scheduler called Slurm.
When I write the exact same expression (as in the second paragraph) within the batch job file, and then I submit the job using sbatch, it is immediatelly terminated and does not return any error or output that can help me understand the problem.
I think it has to do with having Rscript in $PATH, but even though I added the directory where Rscript is located to $PATH by: PATH=$PATH:path/to/R/build/R-3.4.0/lib64/R/bin, the problem remains.
Is there a way that I can make Rscript be run in a Slurm batch job?
You'll need to keep the environment of your SLURM script as bash
#!/bin/bash
Since you can run your R script from the command line, it likely means the path to R is already included in your $PATH. On the command line, you might already do something like:
Rscript ./path-to-script/script
To run R from within your SLURM script, it's the same as running from the command line:
Rscript ./path-to-script/script
My Mac OS command line application is making Unix calls such as:
system("rm -rf /Users/stu/Developer/file);
perfectly successfully.
So why is the following not changing the current directory?
system("cd /Users/me/whatever");
system("pwd"); //cd has not changed
Because
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
So each command is executed independently, each in a new instance of the shell.
So your first call spawns a new sh (with your current working directory), changes directories, and then exits. Then the second call spawns a new sh (again in your CWD).
See the man page for system().
The better solution is to not use system. It has some inherent flaws that can leave you open to security vulnerabilities. Instead of executing system() commands, you should use the equivalent POSIX C functions. Everything that you can do from the command-line, you can do with C functions (how do you think those utilities work?)
Instead of system("rm -rf ...") use this.
Instead of system("cd ...") use chdir().
Instead of system("pwd ...") use getcwd().
There are some differences, of course, but these are the fundamental equivalents of what you're trying to do.
Is there any way for changing the interpreter in the middle of a bash script
For instance start with:
#!/bin/bash
Later change to:
#!$drush_location
The reason is because I want to use bash to resolve the location of drush using bash and then pass that var in as an interpreter
You will need to write two scripts and use the first (bash) one to launch the second (drush).
There are other ways to accomplish this, but they are all basically fancy ways of doing the above. For example you could use a here-doc to cram a script contained as a string in your first script into stdin on drush and have it execute that, or even write a temporary file and execute that as a script, but you have to run two processes somehow, you can't change the interpreter on the fly.
Really the thing to do would be to fix your environment so that it can find drush. Then you can use:
#!/usr/bin/env drush
As the hashbang for your drush script. If your system evn can't find it, then fix your search paths until it can!
I'm trying to call a script in Tcl with the command:
exec source <script path>
and I get the error
couldn't execute "source": no such file or directory
How can I call another script from tcl?
Edit: I am running a command I got from another person in my office. I was instructed to run "source " explicitly with source. So in other words, how would I run any command that would work in cshell, in Tcl?
If the script you were given is a cshell script, you can exec it like this:
exec /bin/csh $path_to_script
In effect, this is what the 'source' command does from within an interactive shell. It's not clear whether this is really what you want to do or not (not exactly, but close enough for this discussion).
The reason you can't exec the source command is that exec will only work on executable files (hence the name 'exec'). The source command isn't implemented as an exectuable file, it is a command built-in to the shell. Thus, it can't be exec'd.
If you really feel the need to exec the source command or any other built-in command you can do something like this:
exec /bin/csh -c "source $path_to_script"
In the above example you are execing the c shell, and asking it to run the command "source ". For the specific case of the source command, this doesn't really make much sense.
However, I'm not sure any of this will really do what you expect. Usually if someone says "here's some commands, just do 'source ', it usually just defines some aliases and whatnot to be used from within an interactive shell. Those aliases won't work from within Tcl.
source in csh, like . in bash, executes a script without spawning a new process.
The effect is that any variable that is set in that script is available in current csh session.
Actually, source is a built-in command of csh, thus not available from tcl exec, and using exec without source would not give the specific source effect.
There is no simple way to solve your problem.
source load the source file
you should do:
source <script path>
If you want to execute it, then you need to call the main proc.
another option would be to do:
exec [info nameofexecutable] <scritp path>
Some confusion here. exec runs a separate program, possibly with arguments.
source is not a separate program, it is another Tcl command which reads a file of Tcl commands and executes them, but does not pass arguments. If the other script you are trying to call is written to be run on from the command line, it will expect to find its arguments as a list in variable argv. You can fake this by setting argv to the list of arguments before running source, eg.
set argv {first_arg second_arg}
source script_path
Alternatively you could use exec to start a whole separate Tcl executable and pass it the script and arguments:
exec script_path first_arg second_arg
the error speaks for itself. Make sure you give the correct path name, specify full path if necessary. and make sure there is indeed the file exists in that directory
Recently I wanted to set some UNIX environment variables by sourcing a shell script and stumbled across the same problem. I found this simple solution that works perfectly for me:
Just use a little 3-line wrapper script that executes the source command in a UNIX shell before your Tcl script is started.
Example:
#!/bin/csh
source SetMyEnvironment.csh
tclsh MyScript.tcl