bash: echo: write error: Interrupted system call












9














I want to generate a sorted list with all 8-digit numbers — from 00000000 to 99999999.
I typed in the shell:



f() {
while IFS="" read -r line; do
for i in {0..9}; do
echo "$line$i";
done;
done
}

echo | f | f | f | f | f | f | f | f | tee result.txt | wc -l


response is



bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
99998890


Why have I got these three errors and malformed result.txt ?



I use



GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)



Debian GNU/Linux 9.6 (stretch)



Linux kernel: 4.19.0 #2 SMP Thu Nov 1 15:31:34 EET 2018 x86_64 GNU/Linux










share|improve this question




















  • 2




    I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
    – Kusalananda
    Dec 9 '18 at 9:56








  • 1




    Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
    – Isaac
    Dec 9 '18 at 10:31






  • 1




    Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
    – Kamil Maciorowski
    Dec 9 '18 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 '18 at 12:37












  • Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
    – Kamil Maciorowski
    Dec 9 '18 at 16:32
















9














I want to generate a sorted list with all 8-digit numbers — from 00000000 to 99999999.
I typed in the shell:



f() {
while IFS="" read -r line; do
for i in {0..9}; do
echo "$line$i";
done;
done
}

echo | f | f | f | f | f | f | f | f | tee result.txt | wc -l


response is



bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
99998890


Why have I got these three errors and malformed result.txt ?



I use



GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)



Debian GNU/Linux 9.6 (stretch)



Linux kernel: 4.19.0 #2 SMP Thu Nov 1 15:31:34 EET 2018 x86_64 GNU/Linux










share|improve this question




















  • 2




    I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
    – Kusalananda
    Dec 9 '18 at 9:56








  • 1




    Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
    – Isaac
    Dec 9 '18 at 10:31






  • 1




    Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
    – Kamil Maciorowski
    Dec 9 '18 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 '18 at 12:37












  • Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
    – Kamil Maciorowski
    Dec 9 '18 at 16:32














9












9








9


4





I want to generate a sorted list with all 8-digit numbers — from 00000000 to 99999999.
I typed in the shell:



f() {
while IFS="" read -r line; do
for i in {0..9}; do
echo "$line$i";
done;
done
}

echo | f | f | f | f | f | f | f | f | tee result.txt | wc -l


response is



bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
99998890


Why have I got these three errors and malformed result.txt ?



I use



GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)



Debian GNU/Linux 9.6 (stretch)



Linux kernel: 4.19.0 #2 SMP Thu Nov 1 15:31:34 EET 2018 x86_64 GNU/Linux










share|improve this question















I want to generate a sorted list with all 8-digit numbers — from 00000000 to 99999999.
I typed in the shell:



f() {
while IFS="" read -r line; do
for i in {0..9}; do
echo "$line$i";
done;
done
}

echo | f | f | f | f | f | f | f | f | tee result.txt | wc -l


response is



bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
bash: echo: write error: Interrupted system call
99998890


Why have I got these three errors and malformed result.txt ?



I use



GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)



Debian GNU/Linux 9.6 (stretch)



Linux kernel: 4.19.0 #2 SMP Thu Nov 1 15:31:34 EET 2018 x86_64 GNU/Linux







bash






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 9 '18 at 12:33









ctrl-alt-delor

10.8k41957




10.8k41957










asked Dec 9 '18 at 9:36









hon

945




945








  • 2




    I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
    – Kusalananda
    Dec 9 '18 at 9:56








  • 1




    Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
    – Isaac
    Dec 9 '18 at 10:31






  • 1




    Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
    – Kamil Maciorowski
    Dec 9 '18 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 '18 at 12:37












  • Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
    – Kamil Maciorowski
    Dec 9 '18 at 16:32














  • 2




    I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
    – Kusalananda
    Dec 9 '18 at 9:56








  • 1




    Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
    – Isaac
    Dec 9 '18 at 10:31






  • 1




    Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
    – Kamil Maciorowski
    Dec 9 '18 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 '18 at 12:37












  • Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
    – Kamil Maciorowski
    Dec 9 '18 at 16:32








2




2




I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
– Kusalananda
Dec 9 '18 at 9:56






I can't help but feeling this way of doing it would not be more efficient than seq -w 0 99999999.
– Kusalananda
Dec 9 '18 at 9:56






1




1




Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
– Isaac
Dec 9 '18 at 10:31




Then the question is incomplete/incorrect/badly written or something else. Because the script (when completed with the }) works correctly. @GAD3R
– Isaac
Dec 9 '18 at 10:31




1




1




Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
– Kamil Maciorowski
Dec 9 '18 at 10:47




Note: I can trigger these errors almost on demand. They often appear when I resize my konsole window. Such resizing is almost sufficient in my case, yet not necessary.
– Kamil Maciorowski
Dec 9 '18 at 10:47












I can remove the | tee result.txt, and still get the error.
– ctrl-alt-delor
Dec 9 '18 at 12:37






I can remove the | tee result.txt, and still get the error.
– ctrl-alt-delor
Dec 9 '18 at 12:37














Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
– Kamil Maciorowski
Dec 9 '18 at 16:32




Another note: external executable (/bin/echo in my case) instead of echo builtin makes the function immune (or at least less prone) to this issue.
– Kamil Maciorowski
Dec 9 '18 at 16:32










2 Answers
2






active

oldest

votes


















5














The specific write error: Interrupted system call error is generated when the console window size is changed while the script is being executed.



Doing a:



 trap '' SIGWINCH


will avoid it.



Note that a



 seq 99999999 >result.txt; wc -l <result.txt


Will be both faster and will avoid the SIGWINCH issue.






share|improve this answer



















  • 5




    So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
    – ctrl-alt-delor
    Dec 9 '18 at 12:39



















3














This is actually a bug[a] in bash, and it doesn't happen only on SIGWINCH, but also on any signal for which a trap was set:



{ pid=$BASHPID; trap : USR1; (sleep 1; kill -USR1 $pid) &
printf %0100000d 1; } | sleep 3600
bash: printf: write error: Interrupted system call


It happens because bash fails to either a) set its signal handlers with SA_RESTART (except for the SIGCHLD handler), or b) handle the EINTR when calling write() in the printf and echo builtins.



EINTR ("Interrupted system call") is not a way to indicate an error condition, but a hack which allows the programmer to combine blocking reads/writes/etc with the handling of signals in the main loop. It should never be leaked to the user.



This bug doesn't show up too frequently because it's quite a feat to get the right conditions in place: the write() should be done by a builtin (not by an external command), it should fill up the pipe buffer (the reader at the other end should be much slower or not reading from the pipe at all but still alive), and the script should use traps or the terminal window should be resized.



And because of diverse implementation artifacts, this only affects interrupted write()s, not read()s or open()s (as eg. the blocking open() of a named pipe/fifo).



[a] a form of this was already reported some time ago.






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%2f486908%2fbash-echo-write-error-interrupted-system-call%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    5














    The specific write error: Interrupted system call error is generated when the console window size is changed while the script is being executed.



    Doing a:



     trap '' SIGWINCH


    will avoid it.



    Note that a



     seq 99999999 >result.txt; wc -l <result.txt


    Will be both faster and will avoid the SIGWINCH issue.






    share|improve this answer



















    • 5




      So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
      – ctrl-alt-delor
      Dec 9 '18 at 12:39
















    5














    The specific write error: Interrupted system call error is generated when the console window size is changed while the script is being executed.



    Doing a:



     trap '' SIGWINCH


    will avoid it.



    Note that a



     seq 99999999 >result.txt; wc -l <result.txt


    Will be both faster and will avoid the SIGWINCH issue.






    share|improve this answer



















    • 5




      So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
      – ctrl-alt-delor
      Dec 9 '18 at 12:39














    5












    5








    5






    The specific write error: Interrupted system call error is generated when the console window size is changed while the script is being executed.



    Doing a:



     trap '' SIGWINCH


    will avoid it.



    Note that a



     seq 99999999 >result.txt; wc -l <result.txt


    Will be both faster and will avoid the SIGWINCH issue.






    share|improve this answer














    The specific write error: Interrupted system call error is generated when the console window size is changed while the script is being executed.



    Doing a:



     trap '' SIGWINCH


    will avoid it.



    Note that a



     seq 99999999 >result.txt; wc -l <result.txt


    Will be both faster and will avoid the SIGWINCH issue.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 19 '18 at 1:08

























    answered Dec 9 '18 at 11:39









    Isaac

    11.2k11649




    11.2k11649








    • 5




      So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
      – ctrl-alt-delor
      Dec 9 '18 at 12:39














    • 5




      So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
      – ctrl-alt-delor
      Dec 9 '18 at 12:39








    5




    5




    So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
    – ctrl-alt-delor
    Dec 9 '18 at 12:39




    So what is going on?, why have I not seen this before?, Why is a write error, the correct thing to do?
    – ctrl-alt-delor
    Dec 9 '18 at 12:39













    3














    This is actually a bug[a] in bash, and it doesn't happen only on SIGWINCH, but also on any signal for which a trap was set:



    { pid=$BASHPID; trap : USR1; (sleep 1; kill -USR1 $pid) &
    printf %0100000d 1; } | sleep 3600
    bash: printf: write error: Interrupted system call


    It happens because bash fails to either a) set its signal handlers with SA_RESTART (except for the SIGCHLD handler), or b) handle the EINTR when calling write() in the printf and echo builtins.



    EINTR ("Interrupted system call") is not a way to indicate an error condition, but a hack which allows the programmer to combine blocking reads/writes/etc with the handling of signals in the main loop. It should never be leaked to the user.



    This bug doesn't show up too frequently because it's quite a feat to get the right conditions in place: the write() should be done by a builtin (not by an external command), it should fill up the pipe buffer (the reader at the other end should be much slower or not reading from the pipe at all but still alive), and the script should use traps or the terminal window should be resized.



    And because of diverse implementation artifacts, this only affects interrupted write()s, not read()s or open()s (as eg. the blocking open() of a named pipe/fifo).



    [a] a form of this was already reported some time ago.






    share|improve this answer




























      3














      This is actually a bug[a] in bash, and it doesn't happen only on SIGWINCH, but also on any signal for which a trap was set:



      { pid=$BASHPID; trap : USR1; (sleep 1; kill -USR1 $pid) &
      printf %0100000d 1; } | sleep 3600
      bash: printf: write error: Interrupted system call


      It happens because bash fails to either a) set its signal handlers with SA_RESTART (except for the SIGCHLD handler), or b) handle the EINTR when calling write() in the printf and echo builtins.



      EINTR ("Interrupted system call") is not a way to indicate an error condition, but a hack which allows the programmer to combine blocking reads/writes/etc with the handling of signals in the main loop. It should never be leaked to the user.



      This bug doesn't show up too frequently because it's quite a feat to get the right conditions in place: the write() should be done by a builtin (not by an external command), it should fill up the pipe buffer (the reader at the other end should be much slower or not reading from the pipe at all but still alive), and the script should use traps or the terminal window should be resized.



      And because of diverse implementation artifacts, this only affects interrupted write()s, not read()s or open()s (as eg. the blocking open() of a named pipe/fifo).



      [a] a form of this was already reported some time ago.






      share|improve this answer


























        3












        3








        3






        This is actually a bug[a] in bash, and it doesn't happen only on SIGWINCH, but also on any signal for which a trap was set:



        { pid=$BASHPID; trap : USR1; (sleep 1; kill -USR1 $pid) &
        printf %0100000d 1; } | sleep 3600
        bash: printf: write error: Interrupted system call


        It happens because bash fails to either a) set its signal handlers with SA_RESTART (except for the SIGCHLD handler), or b) handle the EINTR when calling write() in the printf and echo builtins.



        EINTR ("Interrupted system call") is not a way to indicate an error condition, but a hack which allows the programmer to combine blocking reads/writes/etc with the handling of signals in the main loop. It should never be leaked to the user.



        This bug doesn't show up too frequently because it's quite a feat to get the right conditions in place: the write() should be done by a builtin (not by an external command), it should fill up the pipe buffer (the reader at the other end should be much slower or not reading from the pipe at all but still alive), and the script should use traps or the terminal window should be resized.



        And because of diverse implementation artifacts, this only affects interrupted write()s, not read()s or open()s (as eg. the blocking open() of a named pipe/fifo).



        [a] a form of this was already reported some time ago.






        share|improve this answer














        This is actually a bug[a] in bash, and it doesn't happen only on SIGWINCH, but also on any signal for which a trap was set:



        { pid=$BASHPID; trap : USR1; (sleep 1; kill -USR1 $pid) &
        printf %0100000d 1; } | sleep 3600
        bash: printf: write error: Interrupted system call


        It happens because bash fails to either a) set its signal handlers with SA_RESTART (except for the SIGCHLD handler), or b) handle the EINTR when calling write() in the printf and echo builtins.



        EINTR ("Interrupted system call") is not a way to indicate an error condition, but a hack which allows the programmer to combine blocking reads/writes/etc with the handling of signals in the main loop. It should never be leaked to the user.



        This bug doesn't show up too frequently because it's quite a feat to get the right conditions in place: the write() should be done by a builtin (not by an external command), it should fill up the pipe buffer (the reader at the other end should be much slower or not reading from the pipe at all but still alive), and the script should use traps or the terminal window should be resized.



        And because of diverse implementation artifacts, this only affects interrupted write()s, not read()s or open()s (as eg. the blocking open() of a named pipe/fifo).



        [a] a form of this was already reported some time ago.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 19 '18 at 1:10









        Isaac

        11.2k11649




        11.2k11649










        answered Dec 11 '18 at 4:01









        mosvy

        6,0211425




        6,0211425






























            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.





            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486908%2fbash-echo-write-error-interrupted-system-call%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

            Plaza Victoria

            Puebla de Zaragoza

            Musa