Segmentation fault output is suppressed when piping stdin into a function. Why? 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 Results Why I closed the “Why is Kali so hard” questionDoes `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?

How to find all the available tools in mac terminal?

Is "Reachable Object" really an NP-complete problem?

Significance of Cersei's obsession with elephants?

Amount of permutations on an NxNxN Rubik's Cube

Did MS DOS itself ever use blinking text?

Why are the trig functions versine, haversine, exsecant, etc, rarely used in modern mathematics?

Has negative voting ever been officially implemented in elections, or seriously proposed, or even studied?

How can I use the Python library networkx from Mathematica?

Why are both D and D# fitting into my E minor key?

Circuit to "zoom in" on mV fluctuations of a DC signal?

Would "destroying" Wurmcoil Engine prevent its tokens from being created?

Is it a good idea to use CNN to classify 1D signal?

Trademark violation for app?

What's the meaning of "fortified infraction restraint"?

Do I really need to have a message in a novel to appeal to readers?

Around usage results

8 Prisoners wearing hats

How to answer "Have you ever been terminated?"

What does the "x" in "x86" represent?

For a new assistant professor in CS, how to build/manage a publication pipeline

Can melee weapons be used to deliver Contact Poisons?

Where are Serre’s lectures at Collège de France to be found?

What is the escape velocity of a neutron particle (not neutron star)

Using et al. for a last / senior author rather than for a first author



Segmentation fault output is suppressed when piping stdin into a function. Why?



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 Results
Why I closed the “Why is Kali so hard” questionDoes `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;








6















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 


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 


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?










share|improve this question



















  • 3





    FWIW, I can confirm the same behaviour with Bash 5.0.3.

    – Kusalananda
    Apr 13 at 20:43







  • 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
    Apr 13 at 20:58

















6















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 


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 


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?










share|improve this question



















  • 3





    FWIW, I can confirm the same behaviour with Bash 5.0.3.

    – Kusalananda
    Apr 13 at 20:43







  • 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
    Apr 13 at 20:58













6












6








6








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 


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 


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?










share|improve this question
















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 


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 


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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 13 at 20:38







Dun Peal

















asked Apr 13 at 20:27









Dun PealDun Peal

1645




1645







  • 3





    FWIW, I can confirm the same behaviour with Bash 5.0.3.

    – Kusalananda
    Apr 13 at 20:43







  • 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
    Apr 13 at 20:58












  • 3





    FWIW, I can confirm the same behaviour with Bash 5.0.3.

    – Kusalananda
    Apr 13 at 20:43







  • 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
    Apr 13 at 20:58







3




3





FWIW, I can confirm the same behaviour with Bash 5.0.3.

– Kusalananda
Apr 13 at 20:43






FWIW, I can confirm the same behaviour with Bash 5.0.3.

– Kusalananda
Apr 13 at 20:43





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
Apr 13 at 20:58





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
Apr 13 at 20:58










1 Answer
1






active

oldest

votes


















6














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.






share|improve this answer























    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
    );



    );













    draft saved

    draft discarded


















    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









    6














    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.






    share|improve this answer



























      6














      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.






      share|improve this answer

























        6












        6








        6







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 13 at 21:38









        Michael HomerMichael Homer

        51.3k8142179




        51.3k8142179



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Sum ergo cogito? 1 nng

            三茅街道4182Guuntc Dn precexpngmageondP