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

... 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

I've tried:

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


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


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

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


1 Answer 1


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.

  • 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, 2013 at 19:29
  • 9
    @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. Jun 25, 2013 at 19:42
  • 4
    @StéphaneChazelas (...) which means something completely different You left me wondering what it means in this case...:) Dec 9, 2014 at 13:52
  • 6
    @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). Dec 9, 2014 at 13:59
  • 8
    @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). Dec 9, 2014 at 14:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .