background:
My colleagues and I all login a AIX server with user "root", after login everyone loads their .profile/.kshrc/.netrc etc., then start their work, to execute their own shell scripts.
problem:
when I crontab a script, it will fail because some cmds in it is only defined in my own environment.
The failure remains even I add the sentences of source the .profile/.kshrc/.netrc in the script. It appears it just can not remember the former system setting.
question:
How can I edit the script to get the task ran on my own environment?
A script run by cron should set its own PATH to assure it's starting from a known situation.
Make an inventory of all external commands used by the script, list the directories where they live, then add a line to the top of the script:
PATH=/first/dir:/second/dir
Etc...
In most case you want to include /usr/bin and/or /bin -- for scripts run as root /usr/sbin is another favourite.
Related
I have a remote script on a machine (B) which works perfectly when I run it from machine (B). I wanted to run the script via ssh from machine (A) using:
ssh usersm#${RHOST} './product/2018/requests/inbound/delDup.sh'
However, machine (A) complains about the contents of the remote script (2018req*.txt is a variable defined at the beginning of the script):
ls: cannot access 2018req*.txt: No such file or directory
From the information provided, it's hard to do more than guess. So here's a guess: when you run the script directly on machine B, do you run it from your home directory with ./product/2018/requests/inbound/delDup.sh, or do you cd into the product/2018/requests/inbound directory and run it with ./delDup.sh? If so, using 2018req*.txt will look in different places; basically, it looks in the directory that you were in when you ran the script. If you cded to the inbound directory locally, it'll look there, but running it remotely doesn't change to that directory, so 2018req*.txt will look for files in the home directory.
If that's the problem, I'd rewrite the script to cd to the appropriate directory, either by hard-coding the absolute path directly in the script, or by detecting what directory the script's in (see "https://stackoverflow.com/questions/59895/getting-the-source-directory-of-a-bash-script-from-within" and BashFAQ #28: "How do I determine the location of my script? I want to read some config files from the same place").
BTW, anytime you use cd in a script, you should test the exit status of the cd command to make sure it succeeded, because if it didn't the rest of the script will execute in the wrong place and may do unexpected and unpleasant things. You can use || to run an error handler if it fails, like this:
cd somedir || {
echo "Cannot cd to somedir" >&2
exit 1
}
If that's not the problem, please supply more info about the script and the situation it's running in (i.e. location of files). The best thing to do would be to create a Minimal, Complete, and Verifiable example that shows the problem. Basically, make a copy of the script, remove everything that isn't relevant to the problem, make sure it still exhibits the problem (otherwise you removed something that was relevant), and add that (and file locations) to the question.
First of all when you use SSH, instead of directly sending the output (stdout and stderr) to the monitor, the remote machine/ssh server sends the data back to the machine from which you started the ssh connection. The ssh client running in your local machine will just display it (except if you redirect it of course).
Now, from the information you have provided, it looks like the files are not present on server (B) or not accessible (last but not least, are you sure your ls target the proper directory? ) you could display the current directory in your script before running the ls command for debugging purpose.
Per the title, I'd like to have a .sh file which I can drop into a directory and then:
Run http-server (the simple node server) in the current directory
Open Chrome and point it to that server
The idea is that when I'm developing I can quickly run this bash file and see the current version of whatever html/css/javascript website I am working on. My issue is that if you run a command in a bash file, it isn't run in the current working directory, but rather in the root directory (as far as I can tell). So if I just write http-server in my file, it will run a server not in the current directory, but in ./.
To fix this, I want to cd to the directory first, and then run the script. current_dir=$(pwd) will give me something close to the current directory, but I can't put that directly into a cd command because it (1) doesn't have quotes around it, so spaces in directory names will make it not work, and (2) it starts with /C/ instead of /C:/. Can anyone advise me on how to fix this?
My current code looks as follows.
curr_dir=$(pwd)
cd $curr_dir
http-server
start chrome localhost/XXX
And, as mentioned, results in the http-server command being run in the wrong place:
Starting up http-server, serving ./
Available on:
http://192.168.56.1:8081
http://192.168.1.21:8081
http://127.0.0.1:8081
Hit CTRL-C to stop the server
e: For anyone who happens on this later, this isn't actually a problem -- see the accepted answer. I had another typo.
No; the commands you run always run in the current directory. Otherwise, if your hypothesis were correct, e.g. ls would always show the files in the root directory.
If you want to run a command which is in a different directory, you want
../relative/path/to/command
or
/absolute/path/to/command
Neither of these change the current directory of the shell. The current working directory of the process you create will remain the directory you were in when you run this command. (Even if you run it in the background and subsequently change to a different directory in your interactive shell, for example.)
If you want the command to run in the directory where the script lives on the disk, something like this can occasionally be useful.
cd "$(dirname "$0")"
but again, most of the time, you want and need your commands to run in the current directory.
(There are situations where you want a script to process data files in a fixed location, but these are rare exceptions. Until you have such a situation, consider it a bug to use cd in a shell script.)
If you have a command http-server somewhere on your PATH, just http-server will run that. You should normally not have the current directory on the PATH, but to run the binary in the current directory instead of from anywhere on the PATH, you say so:
./http-server
I am running an SQL script from bash. One of the scripts seems to be running fine, but the other script fails. Can you please advise what might be the cause for the same?
#!/bin/bash
sqlplus -S user/password#database << EOF
whenever sqlerror exit sql.sqlcode;
set echo off
set heading off
#MyScript1
#MyScript2
exit;
EOF
Error:
SP2-0310: unable to open file "MyScript2.sql"
In Unix the access level for both is:
-rwxrwxrwx MyScript1.sql
-rwxrwxrwx MyScript2.sql
The error does give an indication that it is not able to access the file MyScript2.sql. But what I am curious about is how come it can access MyScript1.sql which is present in the same folder, but not MyScript2.sql?
Also if I run the file just in unix (using SQL*Plus) from the folder where the files are present it works fine. But if I run the same from a different folder it doesn't. Below example will explain it better
/Folder/having/the/files
both MyScript1.sql and MyScript2.sql run fine
/Some/random/folder
MyScript1.sql runs fine , but MyScript2.sql errors out
You said:
if I run the file just in unix (using SQL*Plus) from the folder where the
files are present it works fine. But if I run the same from a
different folder it doesn't.
If you run the bash script from a different folder to where you have the SQL files, how do you expect SQL*Plus to know where to find those? The question becomes not 'why can't it see MyScript2.sql, but why it can see MyScript1.sql. The obvious answer is that it can't, or at least can't see the version of the file you think it's seeing.
From the SQL*Plus documentation:
SQL*Plus searches for SQL scripts, including login.sql, in the current
directory and then in the directories specified by SQLPATH, and in the
subdirectories of SQLPATH directories.
So if you haven't given the full path to the SQL file, it will search in the current working directory - where you are sitting when you execute the bash script, not the directory the bash script is in, i.e. what pwd shows - and the in $SQLPATH if it is set.
That suggests you have a copy of MyScript1.sql in one of those places, or possibly a soft link to your real file. If I had to guess, I'd speculate that you originally wrote MyScript.sql the same directory as the script, then copied it to another directory before writing MyScript2.sql. In any case, the MyScript1.sql you're running might be out of date, or is likely to become so in the future.
The short answer is to give the full path to the SQL files, either as part of the # command, or by changing to that directory in the bash script before launching SQL*Plus.
I did try to find the answer online but unfortunately came up empty handed. Searching for './' in combination with other keywords brings up many hits, but none that helped...
Anyhow, as you can probably tell, I am rather new to MacOs. I am running mongo from the shell.
I cd into the /bin folder and start the mongo daemon with:
'./mongod'
.
If I just enter 'mongod', I get the following error:
'-bash: mongod: command not found'
What does the
'./'
in './mongod' stand for? Why is it needed? Why can't I just execute mongo by typing mongod. After all, I am in the correct directory.
After all, I am in the correct directory
But that directory isn't in the PATH. The gist of the matter is that when the shell wants to execute something it looks into a list of directories (specified in a variable called PATH). And the current directory isn't in that list.
As explained in the answer by cnicutar the shell tries to match the command you enter with executables in the directories that are listed in the PATH environment variable.
Although you could add the current directory to the PATH, it's probably not a good idea to do it. This article gives some good reasons why Linux doesn't add it by default:
Its a measure to plug possible security holes. You can't run commands
in the current directory without specifically calling them.
ie ./myscript.sh
To stop nasties writing a vicious shell script, placing the script in
an innocent location such as /tmp and getting root to run the script.
Would root run a nefarious script? If the script was named 'ls' and
root did a listing, the script would automatically run.
Is it dangerous, insecure or not-so-smart for any other reason to put a custom shell script to /usr/bin and add /usr/bin to $PATH in order to make a custom script executable from everywhere without ./ and the file extension?
Bonus question: can I assign custom icons to custom executable scripts?
Traditionally, /usr/bin is one of the places where operating system binaries are stored. For custom scripts, you'd use /usr/local/bin. This you have to create yourself if it does not exist and add to $PATH, as you mentioned.
Icons are a GUI thing, shell scripts are a CLI thing. They live in separate universes. Nothing prevents you from creating a bridge though. For instance, you can make a shell script and call it foo.command. Opening this from the GUI starts Terminal and runs the script. Since you see the file in the Finder, you can assign it a new icon through the Info pane.
Also, you may want to take a look at the free Platypus application. It allows you to create a full-blown application bundle around a script. The bundle will contain the script, so you won't have to put it in some obscure directory and modify $PATH. If you also need CLI access, this option is less desirable.
I wrote a command line tool for setting the custom icon of a file. You can grab it here.