laumars is correct. Your scripts have several design flaws and you should definitely use exit codes to pass information from one script to the other.
Firstly, you exit script2 with an exit code of 0 instead of something non-zero. The convention is to return 0 only if everything works correctly and any other value designating one error condition. When i write scripts one of the first things (even before i write the actual code) is to think the "interface" to the outside: this is the parameter(s) the script needs and what could go wrong and writing down different error codes for everything. Like in the following:
script: foo.sh [string filename] [int linenumber] [string word]
0=ok (word found at linenumber)
1=word not found
2=file not found
3=misc. error
As you can see you could even guess right now what the script should do, without having seen any code: it searches for a word in a given line number in a given file and returns 0 if it finds it there, 1 otherwise. You don't need much more documentation than this to know everything you need to know about it if you want to call it from your script, correct?
Second, your scripts terminate simply somewhere. This works, because at the end of every script the shell implies an "exit 0", if the end of file is reached. Relying on this is not good style, get control over your scripts termination. Your script2 could look like:
#!/bin/bash
if [[ -s err.log ]]; then
cat err.log
exit 0
fi
exit 1
You can see that i removed the messages too. The reason is that you should write every script to be as versatile as possible. Putting error messages into it may be fine within the context of script1, but probably not in the context of some other script you will write and which might want to use script2 too. Therefore put the error messages in script1 and the pure functionality into script2.
Lets see script1 after some changes according to this:
#!/bin/bash
echo "Before ..."
./script2.sh
if [ $? -gt 0 ] ; then
echo "err.log has size 0 - please check!"
echo "exiting... "
exit 1
fi
echo "After ..."
exit 0
Now we have one last problem: as you can see the name off the file - "err.log" - is used several times throughout both scripts. Suppose you change the name for some reason. You would have to change it on three different places in two different scripts. Not good and error-prone. We change the name of the file to a variable which we well pass to script2 as a parameter, making the script even more versatile, because we could immediately use it to display another file without even changing it - simply by passing another filename as parameter as we call it:
script2:
#!/bin/bash
# display a file passed in $1 and return 1 if it is size 0, otherwise 0
local file="$1"
if [[ -s "${file}" ]]; then
cat "${file}"
exit 0
fi
exit 1
script1:
#!/bin/bash
local file="err.log"
echo "Before ..."
./script2.sh "${file}"
if [ $? -gt 0 ] ; then
echo "${file} has size 0 - please check!"
echo "exiting... "
exit 1
fi
echo "After ..."
exit 0
A last remark is the usage of "./script2.sh". Do NEVER do this, because it relies on your current shell sessions PWD pointing to where the scripts are located. Store both these scripts in directory /tmp/foo, change to there and call script1 via "./script1" - it will work. Now change to /tmp and call it by "foo/script1" - it will fail, because it will not find script2.
This is a good way to make things complicated for you, especially if your script get more and more complicated. Therefore always use fully qualified paths. You could - again, to make possible changes in the future easier to accomplish - use variables to name these paths, here is a last version of script1, supposed that alll your scripts are located in /tmp/foo:
script1:
#!/bin/bash
local scriptpath="/tmp/foo"
local file="err.log"
# maybe: local="${filepath}/err.log" where filepath is defined previously
echo "Before ..."
${scriptpath}/script2.sh "${file}"
if [ $? -gt 0 ] ; then
echo "${file} has size 0 - please check!"
echo "exiting... "
exit 1
fi
echo "After ..."
exit 0
I hope this helps.
bakunin
. Not trying to be lazy , but would have been great if we had a way to exit out of the chain of calling shellScripts at once.