Possible redirection bug in zsh 5x
Clash Royale CLAN TAG#URR8PPP
The following command produces different outputs in zsh v. 4.x and 5.x:
grep -v foo >&2
3>&1
(This code is supposed to illustrate how to selectively suppress some of the output sent to stderr by a program; in this case, the warning foo is being suppressed selectively, while the warning bar is allowed to go through; note that in the end, stderr and stdout streams remain separate.)
On v 4.x the output I see at the terminal is as desired/expected:
X
Y
1
2
WARNING: bar
(You may see a different ordering of the WARNING: bar line relative to the other ones.)
On v 5.0.7 (Debian) and 5.1.1 (Darwin), however, what I see at the terminal is this:
X
Y
1
2
WARNING: bar
X
Y
1
2
IOW, the lines that should be sent to stdout appear twice.
I figure there are three possibilities:
- this is a bug in v. 5.x (in which case my question is: is there a workaround?)
- I have not properly configured my v. 5.x zsh (in which case my question is: how should I configure my v. 5.x zsh to get the desired behavior?);
- there is a bug in v. 4.x, but not in v. 5.x, that masked a bug in my code (in which case my question is: how could I fix my code to get the desired behavior in v 5.x?)
zsh io-redirection
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
add a comment |
The following command produces different outputs in zsh v. 4.x and 5.x:
grep -v foo >&2
3>&1
(This code is supposed to illustrate how to selectively suppress some of the output sent to stderr by a program; in this case, the warning foo is being suppressed selectively, while the warning bar is allowed to go through; note that in the end, stderr and stdout streams remain separate.)
On v 4.x the output I see at the terminal is as desired/expected:
X
Y
1
2
WARNING: bar
(You may see a different ordering of the WARNING: bar line relative to the other ones.)
On v 5.0.7 (Debian) and 5.1.1 (Darwin), however, what I see at the terminal is this:
X
Y
1
2
WARNING: bar
X
Y
1
2
IOW, the lines that should be sent to stdout appear twice.
I figure there are three possibilities:
- this is a bug in v. 5.x (in which case my question is: is there a workaround?)
- I have not properly configured my v. 5.x zsh (in which case my question is: how should I configure my v. 5.x zsh to get the desired behavior?);
- there is a bug in v. 4.x, but not in v. 5.x, that masked a bug in my code (in which case my question is: how could I fix my code to get the desired behavior in v 5.x?)
zsh io-redirection
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
1
It's worth mentioning that bothdashandbashproduce the same behaviour aszsh4, which lends credence to the hypothesis that the original behaviour was correct.
– Celada
Mar 5 '16 at 19:42
add a comment |
The following command produces different outputs in zsh v. 4.x and 5.x:
grep -v foo >&2
3>&1
(This code is supposed to illustrate how to selectively suppress some of the output sent to stderr by a program; in this case, the warning foo is being suppressed selectively, while the warning bar is allowed to go through; note that in the end, stderr and stdout streams remain separate.)
On v 4.x the output I see at the terminal is as desired/expected:
X
Y
1
2
WARNING: bar
(You may see a different ordering of the WARNING: bar line relative to the other ones.)
On v 5.0.7 (Debian) and 5.1.1 (Darwin), however, what I see at the terminal is this:
X
Y
1
2
WARNING: bar
X
Y
1
2
IOW, the lines that should be sent to stdout appear twice.
I figure there are three possibilities:
- this is a bug in v. 5.x (in which case my question is: is there a workaround?)
- I have not properly configured my v. 5.x zsh (in which case my question is: how should I configure my v. 5.x zsh to get the desired behavior?);
- there is a bug in v. 4.x, but not in v. 5.x, that masked a bug in my code (in which case my question is: how could I fix my code to get the desired behavior in v 5.x?)
zsh io-redirection
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
The following command produces different outputs in zsh v. 4.x and 5.x:
grep -v foo >&2
3>&1
(This code is supposed to illustrate how to selectively suppress some of the output sent to stderr by a program; in this case, the warning foo is being suppressed selectively, while the warning bar is allowed to go through; note that in the end, stderr and stdout streams remain separate.)
On v 4.x the output I see at the terminal is as desired/expected:
X
Y
1
2
WARNING: bar
(You may see a different ordering of the WARNING: bar line relative to the other ones.)
On v 5.0.7 (Debian) and 5.1.1 (Darwin), however, what I see at the terminal is this:
X
Y
1
2
WARNING: bar
X
Y
1
2
IOW, the lines that should be sent to stdout appear twice.
I figure there are three possibilities:
- this is a bug in v. 5.x (in which case my question is: is there a workaround?)
- I have not properly configured my v. 5.x zsh (in which case my question is: how should I configure my v. 5.x zsh to get the desired behavior?);
- there is a bug in v. 4.x, but not in v. 5.x, that masked a bug in my code (in which case my question is: how could I fix my code to get the desired behavior in v 5.x?)
zsh io-redirection
zsh io-redirection
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
edited Dec 20 '18 at 7:25
Rui F Ribeiro
39k1479130
39k1479130
asked Mar 5 '16 at 19:28
kjo
4,04393763
asked Mar 5 '16 at 19:28
kjo
4,04393763
asked Mar 5 '16 at 19:28
kjo
4,04393763
4,04393763
1
It's worth mentioning that bothdashandbashproduce the same behaviour aszsh4, which lends credence to the hypothesis that the original behaviour was correct.
– Celada
Mar 5 '16 at 19:42
add a comment |
1
It's worth mentioning that bothdashandbashproduce the same behaviour aszsh4, which lends credence to the hypothesis that the original behaviour was correct.
– Celada
Mar 5 '16 at 19:42
1
1
It's worth mentioning that both
dash and bash produce the same behaviour as zsh 4, which lends credence to the hypothesis that the original behaviour was correct.– Celada
Mar 5 '16 at 19:42
It's worth mentioning that both
dash and bash produce the same behaviour as zsh 4, which lends credence to the hypothesis that the original behaviour was correct.– Celada
Mar 5 '16 at 19:42
add a comment |
1 Answer
1
active
oldest
votes
Actually, the bug was in 4.0 and has been fixed.
What you're seeing is the effect of the multios options, specific to zsh. If you want to see the same behaviour as in other shells, you need to disable that option setopt nomultios or call zsh as sh.
With multios, in cmd1 >&3 | cmd2, you're redirecting cmd1's stdout to both &3 and the pipe to cmd2. See How can I pipe only stderr in zsh? for more details.
edited Apr 13 '17 at 12:36
Community♦
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
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%2f267855%2fpossible-redirection-bug-in-zsh-5x%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
Actually, the bug was in 4.0 and has been fixed.
What you're seeing is the effect of the multios options, specific to zsh. If you want to see the same behaviour as in other shells, you need to disable that option setopt nomultios or call zsh as sh.
With multios, in cmd1 >&3 | cmd2, you're redirecting cmd1's stdout to both &3 and the pipe to cmd2. See How can I pipe only stderr in zsh? for more details.
edited Apr 13 '17 at 12:36
Community♦
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
add a comment |
Actually, the bug was in 4.0 and has been fixed.
What you're seeing is the effect of the multios options, specific to zsh. If you want to see the same behaviour as in other shells, you need to disable that option setopt nomultios or call zsh as sh.
With multios, in cmd1 >&3 | cmd2, you're redirecting cmd1's stdout to both &3 and the pipe to cmd2. See How can I pipe only stderr in zsh? for more details.
edited Apr 13 '17 at 12:36
Community♦
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
add a comment |
Actually, the bug was in 4.0 and has been fixed.
What you're seeing is the effect of the multios options, specific to zsh. If you want to see the same behaviour as in other shells, you need to disable that option setopt nomultios or call zsh as sh.
With multios, in cmd1 >&3 | cmd2, you're redirecting cmd1's stdout to both &3 and the pipe to cmd2. See How can I pipe only stderr in zsh? for more details.
edited Apr 13 '17 at 12:36
Community♦
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
Actually, the bug was in 4.0 and has been fixed.
What you're seeing is the effect of the multios options, specific to zsh. If you want to see the same behaviour as in other shells, you need to disable that option setopt nomultios or call zsh as sh.
With multios, in cmd1 >&3 | cmd2, you're redirecting cmd1's stdout to both &3 and the pipe to cmd2. See How can I pipe only stderr in zsh? for more details.
edited Apr 13 '17 at 12:36
Community♦
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
answered Mar 6 '16 at 18:51
Stéphane Chazelas
299k54564913
299k54564913
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
add a comment |
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
I was very curious about this question myself and I knew I could count on you coming along with the answer :-)
– Celada
Mar 6 '16 at 18:57
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%2f267855%2fpossible-redirection-bug-in-zsh-5x%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
1
It's worth mentioning that both
dashandbashproduce the same behaviour aszsh4, which lends credence to the hypothesis that the original behaviour was correct.– Celada
Mar 5 '16 at 19:42