bash: echo: write error: Interrupted system call

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











up vote
9
down vote

favorite
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



















  • 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 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 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 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 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 at 16:32














up vote
9
down vote

favorite
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



















  • 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 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 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 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 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 at 16:32












up vote
9
down vote

favorite
4









up vote
9
down vote

favorite
4






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 at 12:33









ctrl-alt-delor

10.5k41955




10.5k41955










asked Dec 9 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 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 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 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 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 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 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 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 at 10:47










  • I can remove the | tee result.txt, and still get the error.
    – ctrl-alt-delor
    Dec 9 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 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 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 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 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 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 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 at 10:47












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





I can remove the | tee result.txt, and still get the error.
– ctrl-alt-delor
Dec 9 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 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 at 16:32










2 Answers
2






active

oldest

votes

















up vote
5
down vote



accepted










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 at 12:39

















up vote
3
down vote













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








    up vote
    5
    down vote



    accepted










    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 at 12:39














    up vote
    5
    down vote



    accepted










    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 at 12:39












    up vote
    5
    down vote



    accepted







    up vote
    5
    down vote



    accepted






    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 3 hours ago

























    answered Dec 9 at 11:39









    Isaac

    11k11648




    11k11648







    • 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 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 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 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 at 12:39












    up vote
    3
    down vote













    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


























      up vote
      3
      down vote













      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
























        up vote
        3
        down vote










        up vote
        3
        down vote









        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 2 hours ago









        Isaac

        11k11648




        11k11648










        answered Dec 11 at 4:01









        mosvy

        5,3841323




        5,3841323



























            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

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

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?