bash: echo: write error: Interrupted system call
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
|
show 2 more comments
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
2
I can't help but feeling this way of doing it would not be more efficient thanseq -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 mykonsole
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 ofecho
builtin makes the function immune (or at least less prone) to this issue.
– Kamil Maciorowski
Dec 9 '18 at 16:32
|
show 2 more comments
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
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
bash
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 thanseq -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 mykonsole
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 ofecho
builtin makes the function immune (or at least less prone) to this issue.
– Kamil Maciorowski
Dec 9 '18 at 16:32
|
show 2 more comments
2
I can't help but feeling this way of doing it would not be more efficient thanseq -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 mykonsole
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 ofecho
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
|
show 2 more comments
2 Answers
2
active
oldest
votes
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.
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
add a comment |
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.
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%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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 19 '18 at 1:10
Isaac
11.2k11649
11.2k11649
answered Dec 11 '18 at 4:01
mosvy
6,0211425
6,0211425
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.
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%2f486908%2fbash-echo-write-error-interrupted-system-call%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
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 ofecho
builtin makes the function immune (or at least less prone) to this issue.– Kamil Maciorowski
Dec 9 '18 at 16:32