How to catch /bin/bash: bad interpreter error - bash

recently came across an issue when running a bash script executed in a csh shell. This was outputed: /bin/bash: bad interpreter: No such file or directory. The problem was bash was not on the environment path. After adding bash, this was fixed. I want to make sure that in the future, if this ever happened again for some reason, I can handle this. I am wonder what exit code this is? or is this just printed out on stderr? I want to catch this and fail the main script. Any ideas on how to handle this?
I have this segment:
bash sc142.sh
#####################################################################
# Check for processing errors
#####################################################################
if ($status != 0) then
exit (-1)
endif

I tried this on Debian, the exit status for a bad interpreter error is 126. So you can do:
/path/to/scriptname arg ...
if ( $status == 126 ) then
echo "scriptname failed"
exit 1
endif
Note that a false positive is possible. If the last command in the script you're running exits with status 126, you won't be able to tell the difference.

The exit code will be non-zero. The exact exit code depends on the environment. You may get 127 (command not found) but you may also get another non-zero exit code in certain shells.
In your csh script you can set the -e option which will cause the script to exit immediately if any commands fail.
#!/bin/csh -e
false
echo not printed

Related

Run a command right before a script exits due to failure

Let's say there's this script
#!/bin/zsh
python -c 'a'
which will fail since a isn't defined. Just before the shell script exits, I want to run a command, say echo bye. How can that be achieved?
Flow is to be:
Python command above fails.
bye appears in terminal.
The zsh script exits.
I'd prefer it to affect the python command as little as possible such as indent, putting it in an if block, checking its exit code etc. In real life, the command is in fact multiple commands.
In the script you posted, the fact that the shell exits is unrelated to any error. The shell would exit, because the last argument hast been executed. Take for instance the script
#!/bin/zsh
python -c 'a'
echo This is the End
The final echo will always be exeuted, independent of the python command. To cause the script to exit, when python returns a non-zero exit code, you would write something like
#!/bin/zsh
python -c 'a' || exit $?
echo Successful
If you want to exit a script, whenever the first one of the commands produces a non-zeror exit status, AND at the same time want to print a message, you can use the TRAPZERR callback:
#!/bin/zsh
TRAPZERR() {
echo You have an unhandled non-zero exit code in your otherwise fabulous script
exit $?
}
python -c 'a'
echo Only Exit Code 0 encountered

How to detect "Cannot fork" errors in bash?

For currently unknown reasons, one of our bash-scripts produces "Cannot fork" errors when running a simple line like:
myvar=`mycmd || echo "error"; exit 2`
Obviously the problem is that no new process can be created (forked) so that command fails.
However bash just ignores the error and continues in the script which caused unexpected problems.
As you can see, we already check for errors in the command itself, but the "Cannot fork" error appears before the command is even run.
Is there a way to catch that error and stop bash from execution?
There are actually several problems with this error check, that'll prevent it from properly handing any error, not just "Cannot fork" errors.
The first problem is that || has higher precedence than ;, so mycmd || echo "error"; exit 2 will run echo "error" only if mycmd fails, but it'll run exit 2 unconditionally, whether or not mycmd succeeds or fails.
In order to fix this, you should group the error handling commands with { }. Something like: mycmd || { echo "error"; exit 2; }. Note that a ; or line break before } is required, or the } will be treated as an argument to exit.
(BTW, I sometimes see this shorthanded as mycmd || echo "error" && exit 2. Don't do this. If the echo fails for some weird reason, it won't run the exit.)
Also all of this, the echo and the exit, is run in the subshell created by the backticks (or would be, if that subshell had forked successfully). That means the error message will get saved in myvar rather than printed (error messages should generally be sent to standard error, e.g. echo "error" >&2); and more importantly it'll be the subshell that exits, not the shell that's running the script. The main script will note that the subshell exited with an error... and blithely keep running. (Well, unless you have -e set, but that's a whole other ball of potential bugs.)
The solution to that is to put the || stuff outside the backticks (or `$( ), since that's generally preferred over backticks). That way it happens in the main shell, that's what prints the error, that's what exits if there's an error, etc. This should also solve the "Cannot fork" problem, although I haven't tested it.
So, with all these corrections, it should look something like this:
myvar=$(mycmd) || {
echo "error" >&2
exit 2
}
Oh, and as Charles Duffy pointed out in a comment, if you use something like local myvar=$(mycmd) or export myvar=$(mycmd), the local/export/whatever command will override the exit status from mycmd. If you need to do that, set the variable's properties separately from its value:
local myvar
myvar=$(mycmd) || {
...

shell script execution successful but output has errors, how to determine error and exit main script?

I have a main script. Inside it I call other three shell scripts, A,B and C. All were successful. Exit codes are all equal to zero. However, when I looked into the output file of the first script which is A, it contains an error message. Now I want to exit the main script and not to continue running the other scripts after the script that has output error. Can anyone help me on this? Thanks!
Even if some command in your first bash script results in an error, the script as a whole may complete with exit code 0.
You can check the exit code of any individual command in your script by using the $? variable. This variable stores the exit code of the previous command. This will allow you to check for errors within the script.
The easiest way is to append || exit 1 to the statement which is throwing the error. That will cause the script to exit if the exit code of the command is 1 (i.e. an error).
So assuming you had a command sqlscript and you wanted the entire script to exit if sqlscript exited with a non-zero exit code you would do
sqlscript || exit 1
As a point of trivia, the 1 in exit 1 is not needed. A plain exit command would also exit with the exit status of the last executed command.
Which would be false (code=1) if the sqlscript command fails. If the sqlscript command succeeds, the exit code is the exit code of sqlscript. In that case, the || does not trigger and the exit command is not executed.
I have a main script. Inside it I call other three shell scripts, A,B
and C. All were successful. Exit codes are all equal to zero. However,
when I looked into the output file of the first script which is A, it
contains an error message. Now I want to exit the main script and not
to continue running the other scripts after the script that has output
error.
Since script A doesn't return an error exit code, you have to inspect its output. This is quite easy with grep provided that you have a search string which clearly identifies an error message, e. g.:
# this echo command simulates script A - it outputs "error" and exits with 0:
echo "contains an error message" >StoreKey_All.csv # assumed this output file
grep error StoreKey_All.csv && exit 1 # exit if output has error
# continue with scripts B and C
echo B

How to terminate execution of a fish script from a sourced file?

The exit command when executed from a file being sourced doesn't terminate the execution of the program where it was being sourced, how to do this? Consider this files for a clearer explanation:
a.fish:
source b.fish
echo "This should never run!"
b.fish:
echo "Failing now"
exit 1
This will result in this (undesired output):
Failing now
This should never run!
And the exit status is 0! Is there a solution for B to terminate execution of A as if exit was written in A itself?
It's perfectly working the way you want with bash and zsh. Still, I found a solution for fish:
source b.fish; or exit 1
This will exit a.fish if b.fish exited with exit 1, and will continue otherwise.

Why do bash "set -e" cause exit after a seeming error-free command?

Without using set -e, the script runs as expected, with all results correctly generated.
After adding set -e, it exits after this command:
./NameOfATool > result.txt
When I wrap set +e and set -e around that command, then the script terminates as expected.
Why would it exit, or what might be wrong with the command?
p.s. NameOfAToolis an executable compiled from C code. When I manually type that command, it runs ok without giving an error.
set -e will cause the script to exit if any command returns a non-zero exit status. (Well, there are a bunch of exceptions, but that's the general rule.) So, ./NameOfATool apparently returns a non-zero exit status. This might mean that it actually thinks there's an error, or it might mean that the program was poorly written and doesn't report an appropriate exit status for success, or it might mean that it uses special exit-status values to report specific things (much like the standard utility diff, which returns 0 for "same", 1 for "different", and 2 for "error").
Try set +e in your trap:
set -e;
trap 'x=$?; set +e; echo Hello; false; echo World; exit 22;' ERR
echo Testing
false
echo Never See This
Omit the set +e and you don't see the "World" as the non-zero exit code in the trap exits before the trap is completed.
As #ruakh said, this indicates that the tool is exiting with a nonzero (=error) status. You can prevent this from exiting the script by putting it in a compound command that always succeeds:
./NameOfATool > result.txt || true
If the tool exits with a nonzero status, it runs true, which succeeds; hence, the entire compound command is considered to have succeeded. If the command's exit status is significant (i.e. you need to be able to tell if it exited with status 0, 1, or 2), you can either record it for later use:
./NameOfATool > result.txt && toolStatus=0 || toolStatus=$?
...or use the status directly:
if ./NameOfATool > result.txt; then
# do things appropriate for exit status = 0
else
toolStatus=$?
# do things appropriate for exit status != 0
fi

Resources