Exit the script if any statement fails

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I'm using nested if statements in my shell script. If any statement fails, it has to come out of the script with out executing other sections in the script. I tried using exit 1 and set -e.



I'm not able to use set -e as I have used a few grep statements which would return non zero status.



Could someone please help me How to stop executing a script if any statements fails?







share|improve this question





















  • Doesn’t exit 1 work?
    – Jeff Schaller
    Jul 11 at 18:04










  • I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
    – slm♦
    Jul 11 at 21:05











  • By "any statements" you seem to mean "almost any statements".
    – Kusalananda
    Jul 11 at 21:09














up vote
1
down vote

favorite












I'm using nested if statements in my shell script. If any statement fails, it has to come out of the script with out executing other sections in the script. I tried using exit 1 and set -e.



I'm not able to use set -e as I have used a few grep statements which would return non zero status.



Could someone please help me How to stop executing a script if any statements fails?







share|improve this question





















  • Doesn’t exit 1 work?
    – Jeff Schaller
    Jul 11 at 18:04










  • I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
    – slm♦
    Jul 11 at 21:05











  • By "any statements" you seem to mean "almost any statements".
    – Kusalananda
    Jul 11 at 21:09












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I'm using nested if statements in my shell script. If any statement fails, it has to come out of the script with out executing other sections in the script. I tried using exit 1 and set -e.



I'm not able to use set -e as I have used a few grep statements which would return non zero status.



Could someone please help me How to stop executing a script if any statements fails?







share|improve this question













I'm using nested if statements in my shell script. If any statement fails, it has to come out of the script with out executing other sections in the script. I tried using exit 1 and set -e.



I'm not able to use set -e as I have used a few grep statements which would return non zero status.



Could someone please help me How to stop executing a script if any statements fails?









share|improve this question












share|improve this question




share|improve this question








edited Jul 11 at 21:04









slm♦

233k65479651




233k65479651









asked Jul 11 at 17:58









user_297020

116




116











  • Doesn’t exit 1 work?
    – Jeff Schaller
    Jul 11 at 18:04










  • I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
    – slm♦
    Jul 11 at 21:05











  • By "any statements" you seem to mean "almost any statements".
    – Kusalananda
    Jul 11 at 21:09
















  • Doesn’t exit 1 work?
    – Jeff Schaller
    Jul 11 at 18:04










  • I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
    – slm♦
    Jul 11 at 21:05











  • By "any statements" you seem to mean "almost any statements".
    – Kusalananda
    Jul 11 at 21:09















Doesn’t exit 1 work?
– Jeff Schaller
Jul 11 at 18:04




Doesn’t exit 1 work?
– Jeff Schaller
Jul 11 at 18:04












I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
– slm♦
Jul 11 at 21:05





I'd recommend fixing the grep's that aren't returning correctly as well. Enabling set -e is a level of conformance that you're demanding of your script, so you're basically working against it rather than using its enforcements. Just my $0.02.
– slm♦
Jul 11 at 21:05













By "any statements" you seem to mean "almost any statements".
– Kusalananda
Jul 11 at 21:09




By "any statements" you seem to mean "almost any statements".
– Kusalananda
Jul 11 at 21:09










1 Answer
1






active

oldest

votes

















up vote
3
down vote













You can still use set -e. If you have specific statement which you expect to fail, you simply need to catch the error state and "handle" it:



$ cat 454756.sh
#!/bin/bash
set -e
[[ 1 -eq 2 ]] || :
echo "Still got here!"
$ ./454756.sh
Still got here!


set -e will abort the script on any uncaught error condition. Otherwise you would not be able to use if statements.



# this also still works
set -e
if /bin/false; then
echo "nope"
else
echo "yep"
fi


The incantation || : is a succinct way to "eat" any error thrown by any command, which is handy when you're wanting to use set -e and have specific commands whose failure is perfectly okay.



Another way to do this is to unset -e before the command in question, and reset it afterward:



set -e
do_stuff
set +e
/bin/false
set -e





share|improve this answer

















  • 1




    Might worth mentioning true and : are effectively the same and true is a bit more explicit
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:18






  • 1




    In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:52






  • 1




    Fair enough, I sit corrected.
    – DopeGhoti
    Jul 11 at 18:54










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f454756%2fexit-the-script-if-any-statement-fails%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
3
down vote













You can still use set -e. If you have specific statement which you expect to fail, you simply need to catch the error state and "handle" it:



$ cat 454756.sh
#!/bin/bash
set -e
[[ 1 -eq 2 ]] || :
echo "Still got here!"
$ ./454756.sh
Still got here!


set -e will abort the script on any uncaught error condition. Otherwise you would not be able to use if statements.



# this also still works
set -e
if /bin/false; then
echo "nope"
else
echo "yep"
fi


The incantation || : is a succinct way to "eat" any error thrown by any command, which is handy when you're wanting to use set -e and have specific commands whose failure is perfectly okay.



Another way to do this is to unset -e before the command in question, and reset it afterward:



set -e
do_stuff
set +e
/bin/false
set -e





share|improve this answer

















  • 1




    Might worth mentioning true and : are effectively the same and true is a bit more explicit
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:18






  • 1




    In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:52






  • 1




    Fair enough, I sit corrected.
    – DopeGhoti
    Jul 11 at 18:54














up vote
3
down vote













You can still use set -e. If you have specific statement which you expect to fail, you simply need to catch the error state and "handle" it:



$ cat 454756.sh
#!/bin/bash
set -e
[[ 1 -eq 2 ]] || :
echo "Still got here!"
$ ./454756.sh
Still got here!


set -e will abort the script on any uncaught error condition. Otherwise you would not be able to use if statements.



# this also still works
set -e
if /bin/false; then
echo "nope"
else
echo "yep"
fi


The incantation || : is a succinct way to "eat" any error thrown by any command, which is handy when you're wanting to use set -e and have specific commands whose failure is perfectly okay.



Another way to do this is to unset -e before the command in question, and reset it afterward:



set -e
do_stuff
set +e
/bin/false
set -e





share|improve this answer

















  • 1




    Might worth mentioning true and : are effectively the same and true is a bit more explicit
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:18






  • 1




    In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:52






  • 1




    Fair enough, I sit corrected.
    – DopeGhoti
    Jul 11 at 18:54












up vote
3
down vote










up vote
3
down vote









You can still use set -e. If you have specific statement which you expect to fail, you simply need to catch the error state and "handle" it:



$ cat 454756.sh
#!/bin/bash
set -e
[[ 1 -eq 2 ]] || :
echo "Still got here!"
$ ./454756.sh
Still got here!


set -e will abort the script on any uncaught error condition. Otherwise you would not be able to use if statements.



# this also still works
set -e
if /bin/false; then
echo "nope"
else
echo "yep"
fi


The incantation || : is a succinct way to "eat" any error thrown by any command, which is handy when you're wanting to use set -e and have specific commands whose failure is perfectly okay.



Another way to do this is to unset -e before the command in question, and reset it afterward:



set -e
do_stuff
set +e
/bin/false
set -e





share|improve this answer













You can still use set -e. If you have specific statement which you expect to fail, you simply need to catch the error state and "handle" it:



$ cat 454756.sh
#!/bin/bash
set -e
[[ 1 -eq 2 ]] || :
echo "Still got here!"
$ ./454756.sh
Still got here!


set -e will abort the script on any uncaught error condition. Otherwise you would not be able to use if statements.



# this also still works
set -e
if /bin/false; then
echo "nope"
else
echo "yep"
fi


The incantation || : is a succinct way to "eat" any error thrown by any command, which is handy when you're wanting to use set -e and have specific commands whose failure is perfectly okay.



Another way to do this is to unset -e before the command in question, and reset it afterward:



set -e
do_stuff
set +e
/bin/false
set -e






share|improve this answer













share|improve this answer



share|improve this answer











answered Jul 11 at 18:01









DopeGhoti

39.7k54679




39.7k54679







  • 1




    Might worth mentioning true and : are effectively the same and true is a bit more explicit
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:18






  • 1




    In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:52






  • 1




    Fair enough, I sit corrected.
    – DopeGhoti
    Jul 11 at 18:54












  • 1




    Might worth mentioning true and : are effectively the same and true is a bit more explicit
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:18






  • 1




    In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
    – Sergiy Kolodyazhnyy
    Jul 11 at 18:52






  • 1




    Fair enough, I sit corrected.
    – DopeGhoti
    Jul 11 at 18:54







1




1




Might worth mentioning true and : are effectively the same and true is a bit more explicit
– Sergiy Kolodyazhnyy
Jul 11 at 18:18




Might worth mentioning true and : are effectively the same and true is a bit more explicit
– Sergiy Kolodyazhnyy
Jul 11 at 18:18




1




1




In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
– Sergiy Kolodyazhnyy
Jul 11 at 18:52




In bash source they're implemented via same function, and both return exit status of success no matter what, and take arguments without doing anything
– Sergiy Kolodyazhnyy
Jul 11 at 18:52




1




1




Fair enough, I sit corrected.
– DopeGhoti
Jul 11 at 18:54




Fair enough, I sit corrected.
– DopeGhoti
Jul 11 at 18:54












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f454756%2fexit-the-script-if-any-statement-fails%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay