This is the first time I am trying to run the R file from CygWin terminal.
I have a file named linreg.R and I am in the same directory as file in CygWin terminal.
There is a shell script in the same directory that take in input linreg.R and another data.txt (located at some other place).
When I am running the bash with appropriate inputs, its again and again giving me the same error:
$ ./build_model_from_directory.sh linreg.R /workdir/workdir/prod_data_v.txt lm_try
./build_model_from_directory.sh: line 27: type: Rscript: not found
Rscript is needed for linreg.R. Exiting
When I put something like this:
$./build_model_from_directory.sh linreg.Rscript /workdir/workdir/prod_data_v.txt lm_try
Script assumes linreg.Rscript in same directory
This is the first line of the linreg.R
#!/usr/bin/env Rscript
I have tried setting path to PATH=$PATH:C:\\ProgramFiles\\R\\R-3.0.1\\bin
but of no use. It has changed the PATH but still the script is not running.
Any help will be highly appreciated.
it might be worth your time to add it to your .bashrc file:
echo 'PATH=$PATH:/cygdrive/c/Program\ Files/R/R-3.2.3/bin' >> .bashrc
I figured out the mistake that I was making again and again.
cygpath is used to find out the actual representation of the path of the the directory in UNIX environment
Example:
$ cygpath 'C:\Program Files\R\R-3.0.1\bin'
/cygdrive/c/Program Files/R/R-3.0.1/bin
So we need to make sure that PATH variable has Program Files and not ProgramFiles.
Since UNIX does not understand special characters we need to backscape the space between Program Files
$ PATH=$PATH:/cygdrive/c/Program\ Files/R/R-3.0.1/bin
It started recognizing R files after that.
Related
So this is my script
#!/bin/bash
PATH=/SomeFolder/file2.txt;
scp -3 user#server1:/SomeFolder/file.txt user#server2:$PATH;
I get this error
main.sh: line 3: scp: command not found
If I put /SomeFolder/file2.txt in place of of "$PATH" it still doesn't work - same error. It's only after I remove entire second line (PATH definition) does it work.
I simplified my script, the PATH is defined by executing a script inside another server but that doesn't matter. I tested it like what you see and I concluded that the error is due to PATH being defined in the first place.
It is happening because PATH is a system variable that defines directories where the programs and scripts should be looked for. You can view its value by executing echo $PATH. In your script you are setting PATH to /SomeFolder/file2.txt so the program scp that is usually in /usr/bin/ can't be found. Just change the name of variable PATH in your script to something else.
FILEDIR=/home/myuserdir/audit
FILE=auditreport.csv
The above variable is in my configuration file.
I have this bash script that runs with a configuration file I have:
for file in `ls ${FILEDIR}/${FILE}`
It does see my path, it is going into the root or / directory instead of going into my /home/myuserdir/audit dir. But if I declare the variable in the script instead of the configuration file, it works perfectly and the right directory is found. What am I doing wrong? Unfortunately, I have to run the script with the configuration file for easy customization going forward.
I have tried to wrap the statement in “”, but it still does not work.
The expected results is I would like for the script to go to /home/myuserdir/audit instead of the home directory.
You must source your configfile, not only start it!
my.config
ConfigFileDir=/home/myuserdir/audit
ConfigFile=auditreport.csv
your script
# source my.config at the top of your script
source my.config
# and use the variables
echo "$ConfigFileDir/$ConfigFile"
I am new to TCL scripting and shell scripting. I want to invoke a TCL script from the shell script. I have tried as below.
#!/bin/sh
for i in {1..5}
do
my_script
test_script
done
If I run the script, it is throwing error as follows,
./sample.sh: line 5: my_script: command not found
./sample.sh: line 5: test_script: command not found
Can anyone help me out with this ?
Thanks in advance.
If they cannot be found in your $PATH you have to provide a path to your scripts, e.g.:
./my_myscript # current directory
/path/to/test_script # absolute path
If you haven't made your script executable (with chmod +x) then you need to use:
tclsh my_script.tcl
Or maybe tclsh8.5 /path/to/script.tcl or many variations on that.
If you have made the script executable, check that the directory containing the script is on your PATH (if not, use the full filename of the script or adjust your PATH) and that you've got a suitable #! line. The usual recommended one is:
#!/usr/bin/env tclsh8.5
as that will search your path for the tclsh8.5 executable instead of hard-coding it.
From man tclsh. I guess the second block answers your question.
If you create a Tcl script in a file whose first line is
#!/usr/local/bin/tclsh
then you can invoke the script file directly from your shell if you mark the file as executable. [...]
An even better approach is to start your script files with the following three lines:
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" ${1+"$#"}
This approach has three advantages over the approach in the previous paragraph [...]
You should note that it is also common practice to install tclsh with its version number as part of the name.This has the advantage of allowing multiple
versions of Tcl to exist on the same system at once, but also the disadvantage of making it harder to write scripts that start up uniformly across different versions of Tcl.
We have simple Windows batch files that when an error occurs, an "ONCALL.bat" file is run to display support information that is maintained in a separate oncall.txt text file. This is our SOP.
ONCALL.BAT:
set scriptpath=%~dp0
TYPE "%scriptpath%oncall.txt"
I have zero experience with Unix and Shell scripts and I need to quickly provide a shell script equivalent to run in a Unix environment.
Could someone please provide me the .sh equivalent of this code?
Assuming that the help file and the script are in the same directory:
#!/bin/sh
SCRIPTPATH=`dirname "$0"`
cat "$SCRIPTPATH"/oncall.txt
$0 is the file path of the current script; the dirname command extracts the directory part of it. This way you can avoid using a hard-coded path for the help file within the script.
cat oncall.sh
#!/bin/bash
scriptpath=/path/to/scripts
cat ${scriptpath}/oncall.txt
After you create your file, it can't hurt to run
dos2unix oncall.sh
Just to be sure there are no windows Ctrl-M chars that will totally mystify you with the way they can screw up Unix script processing.
THEN
chmod 755 oncall.sh
To make the script executable.
confirm with
ls -l oncall.sh
You should see listing like
-rwxr-xr-x 1 userName grpname 5263 Nov 21 14:44 oncall.sh
Finally, call the script with a full or relative path, i.e.
./oncall.sh
OR
$PWD/oncall.sh
The first line is called the "shebang" line, and when your script is called, the OS reads the first line of the file, to find out what program to run to interpret the rest of the script file.
You may want/need to use as the first line "shebang" one of the following, but bash is a good guess
#!/bin/ksh
#!/bin/sh
#!/bin/ash
#!/bin/dash
#!/bin/zsh
OR you may worst case, your shell lives in a non-standard directory, then you'll have to spell that out, i.e.
#!/usr/bin/ksh
All shell support debugging arguments for trace and variable expansion like
#!/bin/ksh -vx
Or you can wrap just certain lines to turn debugginng on and off like
set -vx
cat ${scriptpath}/oncall.txt
set +vx
Given that
The ~dp special syntax between the % and the 0 basically says to expand the variable %0 to show the drive letter and path, which gives you the current directory containing the batch file!
I think /path/to/scripts is a reasonable substitute, scriptpath=$PWD would be a direct replacement, as there are no drive letters in Unix. The problem there, is that you either rely on unix PATH var to find your script or you cd /path/to/scripts and then run ./oncall.sh using the relative path./ to find the file without naving added a value to PATH.
IHTH.
I've created a bash shell script file that I can run on my local bash (version 4.2.10) but not on a remote computer (version 3.2). Here's what I'm doing
A script file (some_script.sh) exists in a local folder
I've done $ chmod 755 some_script.sh to make it an executable
Now, I try $ ./some_script.sh
On my computer, this runs fine. On the remote computer, this returns a Command not found error:
./some_script.sh: Command not found.
Also, in the remote version, executable files have stars(*) following their names. Don't know if this makes any difference but I still get the same error when I include the star.
Is this because of the bash shell version? Any ideas to make it work?
Thanks!
The command not found message can be a bit misleading. The "command" in question can be either the script you're trying to execute or the shell specified on the shebang line.
For example, on my system:
% cat foo.sh
#!/no/such/dir/sh
echo hello
% ./foo.sh
./foo.sh: Command not found.
./foo.sh clearly exists; it's the interpreter /no/such/dir/sh that doesn't exist. (I find that the error message varies depending on the shell from which you invoke foo.sh.)
So the problem is almost certainly that you've specified an incorrect interpreter name on line one of some_script.sh. Perhaps bash is installed in a different location (it's usually /bin/bash, but not always.)
As for the * characters in the names of executable files, those aren't actually part of the file names. The -F option to the ls command causes it to show a special character after certain kinds of files: * for executables, / for directories, # for symlinks, and so forth. Probably on the remote system you have ls aliased to ls -F or something similar. If you type /bin/ls, bypassing the alias, you should see the file names without the append * characters; if you type /bin/ls -F, you should see the *s again.
Adding a * character in a command name doesn't do what you think it's doing, but it probably won't make any difference. For example, if you type
./some_script.sh*
the * is a wild card, and the command name expands to a list of all files in the current directory whose names match the pattern (this is completely different from the meaning of * as an executable file in ls -F output). Chances are there's only one such file, so
./some_script.sh* is probably equivalent to ./some_script.sh. But don't type the *; it's unnecessary and can cause unexpected results.