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.
Related
I want to send the path to a bash script which sources some environmental variables as an argument to another bash script to run it and use the environmental variables. It works well with no arguments if I hard coded the path to the bash script to run it works and I can retrieve the environmental variables in the main script. the problem happens when I send the path as an argument it does not want to run it.
for example if the path is /path/script.bash and I send the path as an argument I get the error that /path/env_set: No such a file or directory
I run the script by this line
. $1 (this doesn't work)
. /path/script.bash (this works)
if I use
bash -c $1
the bash file runs but it does not set the environmental variables to use it in the main script
I don't know why env_set replaces the script name when I use arguments. Is there any approach to achieve this or any work around to achieve my goal?
It sounds like the problem could be either with your quoting, or with relative paths.
Quoting isn't just about spaces, it's also about pathname expansion (ie. []?* characters).
Do
. "$1"
(not . $1)
And remember, if you're giving a relative path for the environment script (or that script uses some relative paths), you will have a problem. Those paths are relative to the pwd - which is wherever you happen to be when you execute the main script (not where any of the script files themselves happen to be located, for example).
Finally, you can debug this problem by throwing echo at the start, and running the script (if it's safe to do that):
echo . "$1"
exit # Add exit here if you don't want to run w/o the vars.
Now you can see what you're actually trying to source.
In script 1, in your main code, you can call and run script 2,
. ./script 2
The first . stands for current shell, and the second . for current directory.
which will create the environment variables for you, and configure any other settings as well in the same terminal.
Afterwards when script 2 has finished running, script 1 would continue to run, and your environment variables which was created in script 2, will be accessible for script 1 to use in the same session.
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 would like to write a script that has several commands of the kind
> export PATH=$PREFIX/bin
Where
> $PREFIX = /home/usr
or something else. Instead of typing it into the the Shell (/bin/bash) I would run the script to execute the commands.
Tried it with sh and then with a .py script having the line,
> commands.getstatusoutput('export PATH=$PREFIX/bin')
but these result into the error "bad variable name".
Would be thankful for some ideas!
If you need to adjust PATH (or any other environment variable) via a script after your .profile and equivalents have been run, you need to 'dot' or 'source' the file containing the script:
. file_setting_path
source file_setting_path
The . notation applies to all Bourne shell derivatives, and is standardized by POSIX. The source notation is used in C shell and has infected Bash completely unnecessarily.
Note that the file (file_setting_path) can be specified as a pathname, or if it lives in a directory listed on $PATH, it will be found. It only needs to be readable; it does not have to be executable.
The way the dot command works is that it reads the named file as part of the current shell environment, rather than executing it in a sub-shell like a normal script would be executed. Normally, the sub-shell sets its environment happily, but that doesn't affect the calling script.
The bad variable name is probably just a complaint that $PREFIX is undefined.
Usually a setting of PATH would look something like
export PATH=$PATH:/new/path/to/programs
so that you retain the old PATH but add something onto the end.
You are best off putting such things in your .bashrc so that they get run every time you log in.
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.
For some strange reason, I'm getting a "No such file or directory" error for my $PATH variable. I have tried to edit my path using export, changing it from what it was originally to every permutation from a single directory path to the original.
When there is one directory (e.g., export PATH=/bin), I get "/bin: Is a Directory". But once I add more than one directory (e.g., export PATH=/bin:/sbin), I get "No such file or directory".
I'm curious to see what the cause of this issue is!
RE; your comment:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:/usr/local/mysql/bin: No such file or directory will be generated if you have a line which says:
$PATH
maybe on its own, or maybe you have $PATH=.... That is, the shell is trying to execute a program named:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:/usr/local/mysql/bin
Lose the $ on the left-hand side.
I'm not sure you are using the export variant. You almost certainly have spaces in there and you shouldn't, as per the following transcript:
pax> PATH= /bin
bash: /bin: is a directory
pax> PATH= /bin/sbin
bash: /bin/sbin: No such file or directory
The first is caused because you're setting the path temporarily to an empty string while attempting to run that directory. That's because you can do things like:
pax> xyzzy=1
pax> echo $xyzzy
1
pax> xyzzy=2 bash -c 'echo $xyzzy'
2
pax> echo $xyzzy
1
In other words, it's a way of changing an environment variable for a single command, and having it automatically revert when the command is finished.
The second case is simply because there is no /bin/sbin directory. So it detects that before it complains about the fact that you're trying to run a directory.
Setting a variable in bash is a no-space thing (unless you have spaces in your directory names, in which case they should be quoted). In addition, they need to be colon-sparated. Hence you're looking for things like:
PATH=/bin
PATH=/bin:/sbin
PATH="/bin:/sbin:/directory with spaces in it:$HOME/bin"
The export function will only change the variable for the current terminal session.
Write your PATH inside ~/.bash_profile if you want to change it permanently.
For this modification to work you have to close your current terminal and reopen it.