Segmentation fault output is suppressed when piping stdin into a function. Why? The 2019 Stack...
A pet rabbit called Belle
When did F become S? Why?
What do you call a plan that's an alternative plan in case your initial plan fails?
How to pronounce 1ターン?
Who or what is the being for whom Being is a question for Heidegger?
Do warforged have souls?
How can I protect witches in combat who wear limited clothing?
Create an outline of font
Arduino Pro Micro - switch off LEDs
Is every episode of "Where are my Pants?" identical?
Single author papers against my advisor's will?
University's motivation for having tenure-track positions
Segmentation fault output is suppressed when piping stdin into a function. Why?
How did the audience guess the pentatonic scale in Bobby McFerrin's presentation?
How do you keep chess fun when your opponent constantly beats you?
First use of “packing” as in carrying a gun
Does the AirPods case need to be around while listening via an iOS Device?
What information about me do stores get via my credit card?
Finding the path in a graph from A to B then back to A with a minimum of shared edges
Why is superheterodyning better than direct conversion?
Why does the Event Horizon Telescope (EHT) not include telescopes from Africa, Asia or Australia?
Am I ethically obligated to go into work on an off day if the reason is sudden?
How do I add random spotting to the same face in cycles?
Typeface like Times New Roman but with "tied" percent sign
Segmentation fault output is suppressed when piping stdin into a function. Why?
The 2019 Stack Overflow Developer Survey Results Are In
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
2019 Community Moderator Election ResultsDoes `Segmentation fault` message come under STDERR?Segmentation fault with dialogPiping commands, modify stdin write to stdoutPipe Fail (141) when piping output into tee — why?Segmentation fault when calling a recursive bash functionWhat exactly is the function piping into the other function in this fork bomb :(){ :|: & };:?Why script that kill itself using a signal handler produce segmentation fault?Segmentation fault: 11 encounter while installing a programPiping PID into jstackWhy isn't it possible to read from `stdin` with `read` when piping a script to bash?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Let's define a function to execute a binary:
function execute() { ./binary; }
Then define a second function to pipe a text file into the first function:
function test() { cat in.txt | execute; }
If binary
crashes with a segfault, then calling test
from the CLI will result in a 139
return code, but the error - "Segmentation fault" - will not be printed to the terminal.
"Segmentation fault" does get printed if we define test
to call binary
directly:
function test() { cat in.txt | ./binary; }
It also gets printed if we define to call execute
without piping stdin into it:
function test() { execute; }
Finally, it also gets printed if we redirect in.txt
into execute
directly instead of through a pipe:
function test() { execute <in.txt; }
This was tested on Bash 4.4. Why is that?
bash command-line
add a comment |
Let's define a function to execute a binary:
function execute() { ./binary; }
Then define a second function to pipe a text file into the first function:
function test() { cat in.txt | execute; }
If binary
crashes with a segfault, then calling test
from the CLI will result in a 139
return code, but the error - "Segmentation fault" - will not be printed to the terminal.
"Segmentation fault" does get printed if we define test
to call binary
directly:
function test() { cat in.txt | ./binary; }
It also gets printed if we define to call execute
without piping stdin into it:
function test() { execute; }
Finally, it also gets printed if we redirect in.txt
into execute
directly instead of through a pipe:
function test() { execute <in.txt; }
This was tested on Bash 4.4. Why is that?
bash command-line
3
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
1
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago
add a comment |
Let's define a function to execute a binary:
function execute() { ./binary; }
Then define a second function to pipe a text file into the first function:
function test() { cat in.txt | execute; }
If binary
crashes with a segfault, then calling test
from the CLI will result in a 139
return code, but the error - "Segmentation fault" - will not be printed to the terminal.
"Segmentation fault" does get printed if we define test
to call binary
directly:
function test() { cat in.txt | ./binary; }
It also gets printed if we define to call execute
without piping stdin into it:
function test() { execute; }
Finally, it also gets printed if we redirect in.txt
into execute
directly instead of through a pipe:
function test() { execute <in.txt; }
This was tested on Bash 4.4. Why is that?
bash command-line
Let's define a function to execute a binary:
function execute() { ./binary; }
Then define a second function to pipe a text file into the first function:
function test() { cat in.txt | execute; }
If binary
crashes with a segfault, then calling test
from the CLI will result in a 139
return code, but the error - "Segmentation fault" - will not be printed to the terminal.
"Segmentation fault" does get printed if we define test
to call binary
directly:
function test() { cat in.txt | ./binary; }
It also gets printed if we define to call execute
without piping stdin into it:
function test() { execute; }
Finally, it also gets printed if we redirect in.txt
into execute
directly instead of through a pipe:
function test() { execute <in.txt; }
This was tested on Bash 4.4. Why is that?
bash command-line
bash command-line
edited 1 hour ago
Dun Peal
asked 2 hours ago
Dun PealDun Peal
1545
1545
3
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
1
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago
add a comment |
3
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
1
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago
3
3
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
1
1
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago
add a comment |
1 Answer
1
active
oldest
votes
This diagnostic message is generated by the interactive shell's job control system, for the benefit of the user - it's not from the underlying program that crashed. When you pipe into a shell function a subshell is spawned to run the function, and this subshell is not treated as user-facing. If you call the function normally, it runs within the original shell, and the message is printed.
You can test this out by disabling job control in your current shell
set +m
and then running ./binary
again: now it won't print anything there either. Re-enable job control with set -m
.
Even a bare subshell has the same effect:
( : ; ./binary )
will print no diagnostic (two commands are required in there to avoid a subshell-eliding optimisation). Piping out of the function does it too.
Job control is disabled in the subshell, and even with it enabled manually, it's silenced. This is an unfortunate gap in the system. In a non-interactive shell the message would always be reported through a different mechanism, and anywhere else in an interactive shell it would as well.
If printing the diagnostic is important to you, making a script instead of a function will allow you to make sure it's always included. Since you're using the function in a pipeline, you can't do anything that requires a function anyway, so there's not a major cost to doing so.
I wouldn't go quite as far as to say this is a bug. One possible reason to behave in this way is to make command substitution $(...)
, which also runs a subshell, behave appropriately:
foo=$(echo|test)
shouldn't result in the diagnostic message being stored in foo
, so that pipeline failures result in empty expansions. Another is as a way to temporarily suppress the diagnostic messages deliberately.
add a comment |
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%2f512321%2fsegmentation-fault-output-is-suppressed-when-piping-stdin-into-a-function-why%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
This diagnostic message is generated by the interactive shell's job control system, for the benefit of the user - it's not from the underlying program that crashed. When you pipe into a shell function a subshell is spawned to run the function, and this subshell is not treated as user-facing. If you call the function normally, it runs within the original shell, and the message is printed.
You can test this out by disabling job control in your current shell
set +m
and then running ./binary
again: now it won't print anything there either. Re-enable job control with set -m
.
Even a bare subshell has the same effect:
( : ; ./binary )
will print no diagnostic (two commands are required in there to avoid a subshell-eliding optimisation). Piping out of the function does it too.
Job control is disabled in the subshell, and even with it enabled manually, it's silenced. This is an unfortunate gap in the system. In a non-interactive shell the message would always be reported through a different mechanism, and anywhere else in an interactive shell it would as well.
If printing the diagnostic is important to you, making a script instead of a function will allow you to make sure it's always included. Since you're using the function in a pipeline, you can't do anything that requires a function anyway, so there's not a major cost to doing so.
I wouldn't go quite as far as to say this is a bug. One possible reason to behave in this way is to make command substitution $(...)
, which also runs a subshell, behave appropriately:
foo=$(echo|test)
shouldn't result in the diagnostic message being stored in foo
, so that pipeline failures result in empty expansions. Another is as a way to temporarily suppress the diagnostic messages deliberately.
add a comment |
This diagnostic message is generated by the interactive shell's job control system, for the benefit of the user - it's not from the underlying program that crashed. When you pipe into a shell function a subshell is spawned to run the function, and this subshell is not treated as user-facing. If you call the function normally, it runs within the original shell, and the message is printed.
You can test this out by disabling job control in your current shell
set +m
and then running ./binary
again: now it won't print anything there either. Re-enable job control with set -m
.
Even a bare subshell has the same effect:
( : ; ./binary )
will print no diagnostic (two commands are required in there to avoid a subshell-eliding optimisation). Piping out of the function does it too.
Job control is disabled in the subshell, and even with it enabled manually, it's silenced. This is an unfortunate gap in the system. In a non-interactive shell the message would always be reported through a different mechanism, and anywhere else in an interactive shell it would as well.
If printing the diagnostic is important to you, making a script instead of a function will allow you to make sure it's always included. Since you're using the function in a pipeline, you can't do anything that requires a function anyway, so there's not a major cost to doing so.
I wouldn't go quite as far as to say this is a bug. One possible reason to behave in this way is to make command substitution $(...)
, which also runs a subshell, behave appropriately:
foo=$(echo|test)
shouldn't result in the diagnostic message being stored in foo
, so that pipeline failures result in empty expansions. Another is as a way to temporarily suppress the diagnostic messages deliberately.
add a comment |
This diagnostic message is generated by the interactive shell's job control system, for the benefit of the user - it's not from the underlying program that crashed. When you pipe into a shell function a subshell is spawned to run the function, and this subshell is not treated as user-facing. If you call the function normally, it runs within the original shell, and the message is printed.
You can test this out by disabling job control in your current shell
set +m
and then running ./binary
again: now it won't print anything there either. Re-enable job control with set -m
.
Even a bare subshell has the same effect:
( : ; ./binary )
will print no diagnostic (two commands are required in there to avoid a subshell-eliding optimisation). Piping out of the function does it too.
Job control is disabled in the subshell, and even with it enabled manually, it's silenced. This is an unfortunate gap in the system. In a non-interactive shell the message would always be reported through a different mechanism, and anywhere else in an interactive shell it would as well.
If printing the diagnostic is important to you, making a script instead of a function will allow you to make sure it's always included. Since you're using the function in a pipeline, you can't do anything that requires a function anyway, so there's not a major cost to doing so.
I wouldn't go quite as far as to say this is a bug. One possible reason to behave in this way is to make command substitution $(...)
, which also runs a subshell, behave appropriately:
foo=$(echo|test)
shouldn't result in the diagnostic message being stored in foo
, so that pipeline failures result in empty expansions. Another is as a way to temporarily suppress the diagnostic messages deliberately.
This diagnostic message is generated by the interactive shell's job control system, for the benefit of the user - it's not from the underlying program that crashed. When you pipe into a shell function a subshell is spawned to run the function, and this subshell is not treated as user-facing. If you call the function normally, it runs within the original shell, and the message is printed.
You can test this out by disabling job control in your current shell
set +m
and then running ./binary
again: now it won't print anything there either. Re-enable job control with set -m
.
Even a bare subshell has the same effect:
( : ; ./binary )
will print no diagnostic (two commands are required in there to avoid a subshell-eliding optimisation). Piping out of the function does it too.
Job control is disabled in the subshell, and even with it enabled manually, it's silenced. This is an unfortunate gap in the system. In a non-interactive shell the message would always be reported through a different mechanism, and anywhere else in an interactive shell it would as well.
If printing the diagnostic is important to you, making a script instead of a function will allow you to make sure it's always included. Since you're using the function in a pipeline, you can't do anything that requires a function anyway, so there's not a major cost to doing so.
I wouldn't go quite as far as to say this is a bug. One possible reason to behave in this way is to make command substitution $(...)
, which also runs a subshell, behave appropriately:
foo=$(echo|test)
shouldn't result in the diagnostic message being stored in foo
, so that pipeline failures result in empty expansions. Another is as a way to temporarily suppress the diagnostic messages deliberately.
answered 59 mins ago
Michael HomerMichael Homer
50.9k8141178
50.9k8141178
add a comment |
add a comment |
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.
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%2f512321%2fsegmentation-fault-output-is-suppressed-when-piping-stdin-into-a-function-why%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
3
FWIW, I can confirm the same behaviour with Bash 5.0.3.
– Kusalananda♦
1 hour ago
1
Upon further investigation, this seems to be related to whether the shell is running in interactive or non-interactive mode. The error is printed in non-interactive mode.
– Kusalananda♦
1 hour ago