While executing a shell script involving database connection, my script showed me an Error :sqlplus not found :
sqlplus -s username/paswd#DB_name > /home/user/sql.out << EOF
But when i included the following statement, it started to work:
source ~oracle/.bash_profile
What is the purpose of this above line ?
This includes ~oracle/.bash_profilein the script where the line source ~oracle/.bash_profile is.
In your case it probably add the directory of Oracle bin in your PATH.
see also source/dot man page
That line includes the referenced shell script (in this case the .bash_profile from the Oracle home directory).
It's a simple means of decomposing shell scripts into smaller components and thus enabling reuse.
Related
It is possible to supply batch commands directly with the -b flag, but if the commands become very long, this is no longer an option. Is there a way to give the path to an .scm script that was written to a file, without having to move the file into the scripts directory?
No as far as I know. What you give in the -b flag is a Scheme statement, which implies your function has already been loaded by the script executor process. You can of course add more directories that are searched for scripts using Edit>Preferences>Folders>Scripts.
If you write your script in Python the problem is a bit different since you can alter the Python path before loading the script code but the command line remains a bit long.
I'm trying to run several sets of commands in parallel on a few remote hosts.
I've created a script that constructs these commands, and then writes the output in a local file, something along the lines of:
ssh <me>#<ip1> "command" 2> ./path/to/file/newFile1.txt & ssh <me>#<ip2>
"command" 2> ./path/to/file/newFile2.txt & ssh <me>#<ip2> "command" 2>
./path/to/file/newFile3.txt; ...(same repeats itself, with new commands and new
file names)...
My issue is that, when my script runs these commands, I am getting the following errors:
bash: ./path/to/file/newFile1.txt: No such file or directory
bash: ./path/to/file/newFile2.txt: No such file or directory
bash: ./path/to/file/newFile3.txt: No such file or directory
...
These files do NOT exist but will be written. That being said, the directory paths are valid.
The strange thing is that, if I copy and paste the whole big command, then it works without any issue. I'd rather have it automated tho ;).
Any ideas?
Edit - more information:
My filesystem is the following:
- home
- User
- Desktop
- Servers
- Outputs
- ...
I am running the bash script from home/User/Desktop/Servers.
The script creates the commands that need to be run on the remote servers. First thing first, the script creates the directories where the files will be stored.
outputFolder="./Outputs"
...
mkdir -p ${outputFolder}/f{fileNumb}
...
The script then continues to create the commands that will be called on remotes hosts, and their respective outputs will be placed in the created directories.
The directories are there. Running the commands gives me the errors, however printing and then copying the commands into the same location works for some reason. I have also tried to give the full path to directory, still same issue.
Hope I've been a bit clearer.
If this is the exact error message you get:
bash: ./path/to/file/newFile1.txt: No such file or directory
Then you'll note that there's an extra space between the colon and the dot, so it's actually trying to open a file called " ./path/to/file/newFile1.txt" (without the quotes).
However, to accomplish that, you'd need to use quotes around the filename in the redirection, as in
something ... 2> " ./path/to/file/newFile1.txt"
Or the first character would have to something else than a regular space. A non-breaking space perhaps, possible something that some editor might create if you hit alt-space or such.
I don't believe you've shown enough to correctly answer the question.
This doesn't look like a problem with ssh, but the way you are calling the (ssh) commands.
You say that you are writing the commands into a file... presumably you are then running that file as a script. Could you show the code you use to do that. I believe that's your problem.
I suspect you have made a false assumption about the way the working directory changes when you run a script. It doesn't. You are listing relative paths, so its important to know what they are relative to. That is the most likely reason for it working when you copy and paste it... You are executing from a different working directory.
I am new to bash scripting and was building my script based on another one I had seen. I was "running" the command by simply calling the variable where the command was stored:
$cmd
Solved by using:
eval $cmd
instead. My bad, should have given the full script from the start.
I am going through SQL*Plus script and came across set of lines that has below lines:
#test_data/EMPLOYEE.dat
#test_data/ADDRESS.dat
The .dat has some SQL code inside them. I tried to search in internet what the # symbole indicates but I did not get any results. I am new to SQL*Plus, please let me know what this symbol indicates.
This is about sql*plus scripting, we use this symbol to call scripts from external files.
# is used to call scripts from the external files
From the Oracle docs:
Runs the SQL*Plus statements in the specified script. The script can
be called from the local file system or from a web server. The #
command functions similarly to ## and START.
It is used to run the scripts from another file. eg:
SQL> #PreImport.sql
echo: write error: Bad file descriptor
Throughout my code (through several bash scripts) I encounter this error. It happens when I'm trying to write or append to a (one) file.
LOGRUN_SOM_MUT_ANA=/Volumes/.../logRUN_SOMATIC_MUT_ANA
I use the absolute path for this variable and I use the same file for each script that is called. The file has a bunch of lines just like this. I use the import '.' on each script to get it.
echo "debug level set for $DEBUG_LEVEL" >> ${LOGRUN_SOM_MUT_ANA}
Worth noting:
It typically happens AFTER the FIRST time I write to it.
I read about files 'closing' themselves and yielding this error
I am using the above line in one script, and then calling another script.
I'd be happy to clarify anything.
For others encountering the same stupid error under cygwin in a script that works under a real Linux: no idea why, but it can happen:
1) after a syntax error in the script
2) because cygwin bash wants you to replace ./myScript.sh with . ./myScript.sh (where dot is the bash-style include directive, aka source)
I figured it out, the thumb drive I'm using is encrypted. It outputs to /tmp/ so it's a permission thing. That's the problem!
I'm running Oracle 11g on Linux and I'm trying to run a script which will create my database. This script runs fine on windows, but when I test it on Linux, I get the following error:
SP2-0556: Invalid File Name
The problem may be that the path to the file name has a space in it. I'm going to simplify the problem down to one of the many commands I run in the file to make it simple. The sample command I'm trying to run looks like this:
sqlplus [uname]/[pw] #'../database/My Schema/create_sequence.sql'
the create_sequence.sql file has two simple create sequence commands that run fine by themselves. I strongly suspect it is due to the white space because when I change the directory name from My Schema to MySchema and alter the above sqlplus command accordingly, the script runs fine.
Like I said, this script works in windows with the spaces, but not in Linux. I suspect spaces may not be supported, but I was wondering if anyone knew any different or it there is a work-around?
side note: running a command like:
more ../database/My\ Schema/create_sequence.sql
or
more "../database/My Schema/create_sequence.sql"
prints the contents of the file to the console as you would expect. So, I think this is sqlplus (and linux) specific.
I connected to one of my Linux boxes and was pretty easily able to reproduce this issue. There doesn't seem to be any way that I can find to execute the file with the '#' option from the command line so I think you're left with the following options for work arounds:
Rename the My Schema directory to no longer have a space in it (as well as updating all other scripts that reference it
Execute the file from the directory in which it resides (I confirmed that this works, see below)
Send the file into sqlplus via stdin (see below)
You should also file a report with Oracle support as there may be a simple fix that they can provide.
Example Commands:
From Directory
cd ../database/My\ Schema
sqlplus [uname]/[pw] #create_sequence.sql
Via stdin
sqlplus [uname]/[pw] < ../database/My\ Schema/create_sequence.sql
Well, if this is a Linux issue (see my comment on your question - it works fine on Solaris), you may have to try something along the lines of:
sqlplus [uname]/[pw] < '../database/My Schema/create_sequence.sql'
You run into problems if you're trying to pass parameters to your sql script, however...
EDIT: There seems to be a Metalink issue raised for a very similar problem: "Bug 7150873 SQL scripts with filename containing spaces results in SP2-0556". It is listed as affecting 10.2.0.4 and 11.1. It is supposedly fixed in 10.2.0.5 and 11.2, neither which are available yet. It does say it's a generic issue affecting most/all platforms, so I don't know if this is your problem or not.
The specific text of the issue: "The SQLPLUS START command fails to execute SQL scripts which have a space in the filename."
Just for grins, what happens if you do the following:
sqlplus [uname]/[pw]
start '../database/My Schema/create_sequence.sql'
EDIT2: I don't know if modifying your scripts wholesale is feasible or not, but a workaround might be:
cp '../database/My Schema/file2run.sql' ./temp.sql
sqlplus [uname]/[pw] #temp.sql
rm ./temp.sql
You would need to wrap each sqlplus call this way. Another option would be to create a shell script, say with a name of mysqlplus.sh:
#!/bin/sh
cp $2 ./temp$$
sqlplus $1 #$2
rm ./temp$$
Then modify your build scripts thus:
mysqlplus.sh [uname]/[pw] '../database/My Schema/create_sequence.sql'
According to this thread on the OTN site, SP2-0556 can be caused by invalid white space characters in the file that is being executed. Likely the Linux version of SQL-Plus doesn't know how to deal with Windows newline character(s). Try deleting the existing file and recreating it with your desired commands (you said there are only 2 DDL commands so it should be easy).
If you put quotes around path, it works:
SQL > START "C:\Documents and Settings\Administrator\demobuild.sql"
This does not work:
SQL > START C:\Documents and Settings\Administrator\demobuild.sql
have you tried escaping the white space?
Try:
sqlplus [uname]/[pw] #'../database/My\ Schema/create_sequence.sql'
If you're working with this under linux you can escape the space with a '\' character like such:
sqlplus [uname]/[pw] #../database/My\ Schema/create_sequence.sql
I know it's an old question but I just ran into the same situation and after a lot of tries I made it work and I want to share my solution, it was simply put the path into quotes like this:
#"C:/Users/john/AppData/Roaming/SQL Developer/test.sql";