I see this thread is now marked as solved. I take it that the above suggestions worked for you then? General etiquette recommends that you should acknowledge it explicitly with a follow-up post.
I have a few additional suggestions concerning your script:
1) $(..) is highly recommended over `..`
2) QUOTE ALL OF YOUR VARIABLE EXPANSIONS
. You should never leave the quotes off a parameter expansion unless you explicitly want the resulting string to be word-split by the shell (globbing patterns are also expanded). This is a vitally important concept in scripting, so train yourself to do it correctly now. You can learn about the exceptions later.
When you have longer strings, the usual rule of thumb is to simply quote the longest string possible, including the variables.
#echo "Error at line number in errlinenum.txt "$count
echo "Error at line number in errlinenum.txt $count"
3) Avoid the Useless Use Of Cat
. Tools like awk
can generally accept files as direct arguments.
4) If your purpose is to test a single string against multiple conditions, a case statement
is usually preferred over multiple if
case $input1 in
echo "Error can be ignored as it is caused by an SQL statement or a JOB"
ORA-*) echo "error found"
*) echo $input2 > /dev/null
(What's the purpose of that last command, BTW, since it basically does nothing? If you need a placeholder command, use ":
" (a synonym for the "true
" command), or else just leave it out of the script.
5) If a string is already stored in a variable, it's usually recommended to use parameter substitution
or other built-in string manipulation
techniques, rather than external commands.
#input2=`echo $input1 | cut -b -4`
You can also use globbing
patterns directly in double-bracket tests.
if [[ $input1 == ORA-* ]]
Although in this particular situation you should be able to just include the it in the enclosing case
statement, as I demonstrated above.
6) When using bash
, it's recommended to use [[..]]
for string/file tests, and ((..))
for numerical tests. Avoid using the old [..]
test unless you specifically need POSIX-style portability.
I'm recommending this here particularly to highlight that you should be consistent in their use.