trap on command exit not working unless used in a function or sub-shell
Am experimenting a bit with trap on invalid command return code using a sample code
#!/bin/bash
# Exit on error
trap 'echo 'exiting..';exit' ERR
set -e
h=1
b=$((h+)) # <----- command causing the error
echo $?
echo $b
echo "end"
Am not able to cause the trap to occur even though there is an offending instruction. But the same if I run in a sub-shell as
function junk() {
h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
}
junk
(or) running the entire instructions in a sub-shell as
(h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
)
am able to catch the command failure and the EXIT catches the trap and prints the message accordingly.
Am aware of the usage of set -e
-e errexit When set, the shell exits when a simple command in a command list exits
non-zero (FALSE). This is not done in situations, where the exit code is already checked
(if, while, until, ||, &&)
but I can't find a proper reference where it says happens only on a sub-shell or a function or something similar.
Let me know if I am missing something basic here.
bash shell signals error-handling trap
asked Dec 29 '16 at 10:20
Inian
3,825824
add a comment |
Am experimenting a bit with trap on invalid command return code using a sample code
#!/bin/bash
# Exit on error
trap 'echo 'exiting..';exit' ERR
set -e
h=1
b=$((h+)) # <----- command causing the error
echo $?
echo $b
echo "end"
Am not able to cause the trap to occur even though there is an offending instruction. But the same if I run in a sub-shell as
function junk() {
h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
}
junk
(or) running the entire instructions in a sub-shell as
(h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
)
am able to catch the command failure and the EXIT catches the trap and prints the message accordingly.
Am aware of the usage of set -e
-e errexit When set, the shell exits when a simple command in a command list exits
non-zero (FALSE). This is not done in situations, where the exit code is already checked
(if, while, until, ||, &&)
but I can't find a proper reference where it says happens only on a sub-shell or a function or something similar.
Let me know if I am missing something basic here.
bash shell signals error-handling trap
asked Dec 29 '16 at 10:20
Inian
3,825824
Yourtrap 'echo 'exiting..';exit' ERRdoesn't nest quotes, so you're popping out of quotes for the wordexiting...and then back in again. I suspect that although this works it's not actually what you intend. I would suggest thattrap 'echo "exiting..";exit' ERRmight be better.
– roaima
Dec 29 '16 at 13:56
add a comment |
Am experimenting a bit with trap on invalid command return code using a sample code
#!/bin/bash
# Exit on error
trap 'echo 'exiting..';exit' ERR
set -e
h=1
b=$((h+)) # <----- command causing the error
echo $?
echo $b
echo "end"
Am not able to cause the trap to occur even though there is an offending instruction. But the same if I run in a sub-shell as
function junk() {
h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
}
junk
(or) running the entire instructions in a sub-shell as
(h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
)
am able to catch the command failure and the EXIT catches the trap and prints the message accordingly.
Am aware of the usage of set -e
-e errexit When set, the shell exits when a simple command in a command list exits
non-zero (FALSE). This is not done in situations, where the exit code is already checked
(if, while, until, ||, &&)
but I can't find a proper reference where it says happens only on a sub-shell or a function or something similar.
Let me know if I am missing something basic here.
bash shell signals error-handling trap
asked Dec 29 '16 at 10:20
Inian
3,825824
Am experimenting a bit with trap on invalid command return code using a sample code
#!/bin/bash
# Exit on error
trap 'echo 'exiting..';exit' ERR
set -e
h=1
b=$((h+)) # <----- command causing the error
echo $?
echo $b
echo "end"
Am not able to cause the trap to occur even though there is an offending instruction. But the same if I run in a sub-shell as
function junk() {
h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
}
junk
(or) running the entire instructions in a sub-shell as
(h=1
b=$((h+))
echo "Exit code:$?"
echo $b
echo "end"
echo "Hello"
)
am able to catch the command failure and the EXIT catches the trap and prints the message accordingly.
Am aware of the usage of set -e
-e errexit When set, the shell exits when a simple command in a command list exits
non-zero (FALSE). This is not done in situations, where the exit code is already checked
(if, while, until, ||, &&)
but I can't find a proper reference where it says happens only on a sub-shell or a function or something similar.
Let me know if I am missing something basic here.
bash shell signals error-handling trap
bash shell signals error-handling trap
asked Dec 29 '16 at 10:20
Inian
3,825824
asked Dec 29 '16 at 10:20
Inian
3,825824
asked Dec 29 '16 at 10:20
Inian
3,825824
asked Dec 29 '16 at 10:20
Inian
3,825824
asked Dec 29 '16 at 10:20
Inian
3,825824
3,825824
Yourtrap 'echo 'exiting..';exit' ERRdoesn't nest quotes, so you're popping out of quotes for the wordexiting...and then back in again. I suspect that although this works it's not actually what you intend. I would suggest thattrap 'echo "exiting..";exit' ERRmight be better.
– roaima
Dec 29 '16 at 13:56
add a comment |
Yourtrap 'echo 'exiting..';exit' ERRdoesn't nest quotes, so you're popping out of quotes for the wordexiting...and then back in again. I suspect that although this works it's not actually what you intend. I would suggest thattrap 'echo "exiting..";exit' ERRmight be better.
– roaima
Dec 29 '16 at 13:56
Your
trap 'echo 'exiting..';exit' ERR doesn't nest quotes, so you're popping out of quotes for the word exiting... and then back in again. I suspect that although this works it's not actually what you intend. I would suggest that trap 'echo "exiting..";exit' ERR might be better.– roaima
Dec 29 '16 at 13:56
Your
trap 'echo 'exiting..';exit' ERR doesn't nest quotes, so you're popping out of quotes for the word exiting... and then back in again. I suspect that although this works it's not actually what you intend. I would suggest that trap 'echo "exiting..";exit' ERR might be better.– roaima
Dec 29 '16 at 13:56
add a comment |
1 Answer
1
active
oldest
votes
What you are missing is that set -e and sigspec ERR both apply to command execution (commands that exit with a non-zero value). What you have here with b=$((h+)) is a parsing error. The command is not executed because it is not understood.
Why does it work in a function or sub-shell? Because this parsing error makes the containing script (be it function or a sub-shell) fail as a whole. In other words, this is not b=$((h+)) that triggers your trap (there is no trap set in your sub-shells), this is the failure of the call to junk or to your subshell.
edited yesterday
Jeff Schaller
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expectedb=$((h+))to do.
– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of thebashmanual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »
– roaima
Dec 29 '16 at 14:24
|
show 2 more comments
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',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f333507%2ftrap-on-command-exit-not-working-unless-used-in-a-function-or-sub-shell%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What you are missing is that set -e and sigspec ERR both apply to command execution (commands that exit with a non-zero value). What you have here with b=$((h+)) is a parsing error. The command is not executed because it is not understood.
Why does it work in a function or sub-shell? Because this parsing error makes the containing script (be it function or a sub-shell) fail as a whole. In other words, this is not b=$((h+)) that triggers your trap (there is no trap set in your sub-shells), this is the failure of the call to junk or to your subshell.
edited yesterday
Jeff Schaller
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expectedb=$((h+))to do.
– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of thebashmanual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »
– roaima
Dec 29 '16 at 14:24
|
show 2 more comments
What you are missing is that set -e and sigspec ERR both apply to command execution (commands that exit with a non-zero value). What you have here with b=$((h+)) is a parsing error. The command is not executed because it is not understood.
Why does it work in a function or sub-shell? Because this parsing error makes the containing script (be it function or a sub-shell) fail as a whole. In other words, this is not b=$((h+)) that triggers your trap (there is no trap set in your sub-shells), this is the failure of the call to junk or to your subshell.
edited yesterday
Jeff Schaller
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expectedb=$((h+))to do.
– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of thebashmanual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »
– roaima
Dec 29 '16 at 14:24
|
show 2 more comments
What you are missing is that set -e and sigspec ERR both apply to command execution (commands that exit with a non-zero value). What you have here with b=$((h+)) is a parsing error. The command is not executed because it is not understood.
Why does it work in a function or sub-shell? Because this parsing error makes the containing script (be it function or a sub-shell) fail as a whole. In other words, this is not b=$((h+)) that triggers your trap (there is no trap set in your sub-shells), this is the failure of the call to junk or to your subshell.
edited yesterday
Jeff Schaller
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
What you are missing is that set -e and sigspec ERR both apply to command execution (commands that exit with a non-zero value). What you have here with b=$((h+)) is a parsing error. The command is not executed because it is not understood.
Why does it work in a function or sub-shell? Because this parsing error makes the containing script (be it function or a sub-shell) fail as a whole. In other words, this is not b=$((h+)) that triggers your trap (there is no trap set in your sub-shells), this is the failure of the call to junk or to your subshell.
edited yesterday
Jeff Schaller
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
edited yesterday
Jeff Schaller
38.4k1053125
edited yesterday
Jeff Schaller
38.4k1053125
edited yesterday
Jeff Schaller
38.4k1053125
38.4k1053125
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
answered Dec 29 '16 at 13:39
xhienne
11.9k2654
11.9k2654
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expectedb=$((h+))to do.
– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of thebashmanual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »
– roaima
Dec 29 '16 at 14:24
|
show 2 more comments
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expectedb=$((h+))to do.
– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of thebashmanual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »
– roaima
Dec 29 '16 at 14:24
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
That's great! Can you provide some reference from any of the man pages about this behavior, I'd be happy to accept it!
– Inian
Dec 29 '16 at 13:55
@Inian since it's not valid syntax perhaps you could explain what you would have expected
b=$((h+)) to do.– roaima
Dec 29 '16 at 13:57
@Inian since it's not valid syntax perhaps you could explain what you would have expected
b=$((h+)) to do.– roaima
Dec 29 '16 at 13:57
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Note sure what you meant, that line was the intended offending instruction which I enforced manually.
– Inian
Dec 29 '16 at 14:00
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
@roaima : Wanted a proper reference as per xhienne's answer, if the containing script either a function or a subshell could cause the failure as a whole rather than a single offending instruction
– Inian
Dec 29 '16 at 14:13
2
2
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of the
bash manual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »– roaima
Dec 29 '16 at 14:24
@Inian oh I see. I thought you wanted a reference to the failing command. Anyway, here is the part of the
bash manual that describes this behavour: « If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status [...] »– roaima
Dec 29 '16 at 14:24
|
show 2 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f333507%2ftrap-on-command-exit-not-working-unless-used-in-a-function-or-sub-shell%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Your
trap 'echo 'exiting..';exit' ERRdoesn't nest quotes, so you're popping out of quotes for the wordexiting...and then back in again. I suspect that although this works it's not actually what you intend. I would suggest thattrap 'echo "exiting..";exit' ERRmight be better.– roaima
Dec 29 '16 at 13:56