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.
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.
I have following script hierarchy.
Scripts/master.sql
Scripts/GB/gb.sql
Scripts/GB/user1/insert.sql
master.sql contains simple #script to call gb.sql
e.g.
#GB/gb.sql
gb.sql contains below
#user1/insert.sql
The problem is that if i run master.sql from Scripts directory, i get below error:
unable to find insert.sql
Whereas if I execute gb.sql from GB directory, ir run successfully.
Can you please help me?
SQL*Plus directories are always reletive to the original working directory. Your scripts will need to repeat the full path from the working directory each time.
Change gb.sql to:
#GB/user1/insert.sql
The ## can be used to reference files in the same directory as the running file, but ## does not work with sub directories.
I am trying to run a bash file from install4j6. install4j does indeed try to run the bash file but it just returns an error at the end of the installation. The error is very generic and has no code reference or anything that will help me determine a solution - just a message that says "Error while executing file."
The only thing I can provide is how I have it setup in install4j6 since I am pretty sure that's my issue.
The bash file is defined in the root of my installation directory distribution tree and is named set_permissions.sh. For the sake of eliminating permissions being a cause, the file permission mode is set to 777 (both in install4j and on the file system).
I believe the issue is related to what I have set as my "working directory". I currently have it set to just ".". Is there a way to debug this further? Maybe get an actual error as to why it's not executing?
Ok, first a few things to check:
make sure that you're running the batch file after the install files step (you mention it being at the root of your install)
best to have the wait for termination checked and a variable for the return code.
redirect stderr to the log file (just in case)
As for working directory, . should work, but you can change it to ${installer:sys.installationDir} to make sure that it references the installation directory chosen by the user. You can also set the executable in the form of ${installer:sys.installationDir}\set_permissions.sh
Also, try and run just your shell script to make sure that it works :)
I am quite new to the Mac Terminal environment.
I donwloaded sqlplus (which is recognised as a UNIX executable program) and then in Terminal I do cd a few times until I arrive in the folder I put this in (\Applications\instantclient_10) in this case.
When I type 'ls' I see a listing of all the files including the sqlplus. So I would then expect to simply type at the Telnet prompt 'sqlplus' and then this would start but instead keep getting
-bash: sqlplus: command not found
This is problem one.
I have now downloaded MySQL and again, when I go to the correct folder (\Library\StarupItems\MySQLCOM) and I type 'ls' I see my files (including MySQLCOM) but when I come to try to 'run' this by simply typing 'MySQLCOM' again the message is:
-base: MySQLCOM: command not found
What am I doing wrong?
Thanks
To run binary/executables in current folder you need to prefix them with ./
./sqlplus
The idea here is that you want to force execution of local file and not run it accidentally. Imagine app that would put ls binary into it's folder and it would automatically run if did ls in that folder.
I can't figure out how to add a directory to the system path. I found out that the command is something like this:
export PATH=$PATH:/my_path/to/my_dir
Example
I run the terminal in the path where my installation directory is located. In this case I'm talking about Play Framework. And I type:
export PATH=$PATH:/to/play20
It looks like nothing happens. In fact, when I type the command "play" (to execute the framework) I get:
-bash: play: command not found
Can someone please give me a decent step-by-step guide?
Execute the command “/to/play20/play help”. If this gives the expected output (help for the play command), then the executable is available, and the problem is in the shell path. If it does not give the expected output, then the executable is not working.
In the former case, ensure you are running the bash shell. (This is the default for recent versions of Mac OS X, but it may be changed for specific accounts.) To do this temporarily, execute the command “bash”. (When you want to exit the temporary shell, execute the command “exit”.) Then execute the export command again. (When the export command works, it changes the variable without displaying any output, so this is normal.) Check the spelling in the export command carefully.
In the latter case, execute “ls -ld /to/play20/play”. If you get a message that the file does not exist, then the executable is not installed correctly, and I cannot help you further. If the file is present, then it is not executable for some reason. This might be because you do not have permission to access it (especially permission to execute it, marked by “x” in certain places in the initial field of the ls output that may contain hyphens, “r”, “w”, and a few other letters) or that it is a symbolic link to a file that does not exist (indicated by an “l” in the first character of the ls output for the file). Lack of permission can be fixed by the chmod command, assuming you have appropriate permissions for changing permissions on the system. If the file is a symbolic link to another file, you may have a bad installation, or the target file may have permission issues (or be another symbolic link, and so on).