Redirect both stderr and stdout to /dev/null with /bin/sh

I have tried all sorts of ways to redirect both stdout and stderr to /dev/null without any success. I have almost my entire life run bash which I've never had this issue with, but for once in BSD I'm stuck with /bin/sh.

What I've tried:

if ls ./python* 2> /dev/null; then
 echo found Python
fi

... which works; if Python is not present it will mute the error messages from ls.
However, if python.tgz is present, a line with be outputted which looks like this:

# ./test.sh
./python-2.7.3p1.tgz

I've tried:

if ls ./python* &> /dev/null; then
 echo found Python
fi

and

if ls ./python* 2>1 > /dev/null; then
 echo found Python
fi

and

if ls ./python* > /dev/null; then
 echo found Python
fi

Nothing really works.
I can only redirect one of the outputs, not both at the same time.

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

add a comment |

What I've tried:

if ls ./python* 2> /dev/null; then
 echo found Python
fi

... which works; if Python is not present it will mute the error messages from ls.
However, if python.tgz is present, a line with be outputted which looks like this:

# ./test.sh
./python-2.7.3p1.tgz

I've tried:

if ls ./python* &> /dev/null; then
 echo found Python
fi

and

if ls ./python* 2>1 > /dev/null; then
 echo found Python
fi

and

if ls ./python* > /dev/null; then
 echo found Python
fi

Nothing really works.
I can only redirect one of the outputs, not both at the same time.

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

add a comment |

What I've tried:

if ls ./python* 2> /dev/null; then
 echo found Python
fi

... which works; if Python is not present it will mute the error messages from ls.
However, if python.tgz is present, a line with be outputted which looks like this:

# ./test.sh
./python-2.7.3p1.tgz

I've tried:

if ls ./python* &> /dev/null; then
 echo found Python
fi

and

if ls ./python* 2>1 > /dev/null; then
 echo found Python
fi

and

if ls ./python* > /dev/null; then
 echo found Python
fi

Nothing really works.
I can only redirect one of the outputs, not both at the same time.

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

What I've tried:

if ls ./python* 2> /dev/null; then
 echo found Python
fi

... which works; if Python is not present it will mute the error messages from ls.
However, if python.tgz is present, a line with be outputted which looks like this:

# ./test.sh
./python-2.7.3p1.tgz

I've tried:

if ls ./python* &> /dev/null; then
 echo found Python
fi

and

if ls ./python* 2>1 > /dev/null; then
 echo found Python
fi

and

if ls ./python* > /dev/null; then
 echo found Python
fi

Nothing really works.
I can only redirect one of the outputs, not both at the same time.

shell io-redirection openbsd

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

edited Jan 2 '18 at 11:59

Jeff Schaller

38.7k1053125

asked Jun 25 '13 at 19:12

Torxed

1,22441634

asked Jun 25 '13 at 19:12

Torxed

1,22441634

asked Jun 25 '13 at 19:12

Torxed

1,22441634

add a comment |

1 Answer
1

active

oldest

votes

This will work in any Posix-compatible shell:

ls good bad >/dev/null 2>&1

You have to redirect stdout first before duplicating it into stderr; if you duplicate it first, stderr will just point to what stdout originally pointed at.

Bash, zsh and some other shells also provide the shortcut

ls good bad &>/dev/null

which is convenient on the command-line but should be avoided in scripts which are intended to be portable.

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

1

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

8

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

2

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

4

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

5

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

|
show 1 more 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
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f80629%2fredirect-both-stderr-and-stdout-to-dev-null-with-bin-sh%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

This will work in any Posix-compatible shell:

ls good bad >/dev/null 2>&1

You have to redirect stdout first before duplicating it into stderr; if you duplicate it first, stderr will just point to what stdout originally pointed at.

Bash, zsh and some other shells also provide the shortcut

ls good bad &>/dev/null

which is convenient on the command-line but should be avoided in scripts which are intended to be portable.

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

1

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

8

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

2

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

4

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

5

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

|
show 1 more comment

This will work in any Posix-compatible shell:

ls good bad >/dev/null 2>&1

You have to redirect stdout first before duplicating it into stderr; if you duplicate it first, stderr will just point to what stdout originally pointed at.

Bash, zsh and some other shells also provide the shortcut

ls good bad &>/dev/null

which is convenient on the command-line but should be avoided in scripts which are intended to be portable.

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

1

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

8

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

2

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

4

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

5

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

|
show 1 more comment

This will work in any Posix-compatible shell:

ls good bad >/dev/null 2>&1

You have to redirect stdout first before duplicating it into stderr; if you duplicate it first, stderr will just point to what stdout originally pointed at.

Bash, zsh and some other shells also provide the shortcut

ls good bad &>/dev/null

which is convenient on the command-line but should be avoided in scripts which are intended to be portable.

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

This will work in any Posix-compatible shell:

ls good bad >/dev/null 2>&1

You have to redirect stdout first before duplicating it into stderr; if you duplicate it first, stderr will just point to what stdout originally pointed at.

Bash, zsh and some other shells also provide the shortcut

ls good bad &>/dev/null

which is convenient on the command-line but should be avoided in scripts which are intended to be portable.

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

edited Dec 19 '18 at 17:52

answered Jun 25 '13 at 19:22

rici

7,4572530

answered Jun 25 '13 at 19:22

rici

7,4572530

answered Jun 25 '13 at 19:22

rici

7,4572530

1

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

8

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

2

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

4

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

5

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

|
show 1 more comment

1

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

8

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

2

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

4

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

5

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

Indeed, i read the bourn shell manual. It stated that later versions of /bin/sh have implemented the &>/dev/null syntax, aparently not so or i have a older version (which i can't echo in any way, running OpenBSD 5.3 tho so should be sufficient)
– Torxed
Jun 25 '13 at 19:29

@Torxed, OpenBSD's sh is based on pdksh. There's no more Bourne shell nowadays. csh introduced >& also available in zsh. bash chose &> (now also supported by zsh and some pdksh derivatives) though it clearly breaks POSIX compliance since foo &> file is perfectly valid POSIX syntax which means something completely different.
– Stéphane Chazelas
Jun 25 '13 at 19:42

@StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:)
– Piotr Dobrogost
Dec 9 '14 at 13:52

@PiotrDobrogost, foo &> file is like foo & > file or foo & : > file, that is run foo in background and open file for writing for no command at all (unlikely to be used like that).
– Stéphane Chazelas
Dec 9 '14 at 13:59

@PiotrDobrogost, >& is not ideal either as it conflicts with the >&2, >&- operators. zsh added it for convenience for csh users (csh doesn't have >&2). They're just syntactic sugar, just use > file 2>&1 which is standard and portable (to Bourne-like shells).
– Stéphane Chazelas
Dec 9 '14 at 14:26

|
show 1 more comment

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

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

搜尋此網誌

mjhjmtu