2

I was recently searching for a way to filter out 'Permission denied' errors while searching for a file using the find command, and I found this link:

How can I exclude all "permission denied" messages from "find"?

Here's an the answer that worked for me from the link:

find . -name "filename" 2>&1 | grep -v 'permission denied'

Although this answer works, I don't fully understand why we need the 2>&1 (redirection of stderr to stdout).

Doesn't the output from the command find . -name "filename" | grep -v 'Permission denied' already redirect to stdout?

Community
  • 1
  • 1
wizurd
  • 3,541
  • 3
  • 33
  • 50
  • 1
    just dump `stderr` to `/dev/null`. no need to pipe to grep. – Jason Hu Jun 15 '15 at 17:57
  • It is enormously important to understand that pruning the error messages will *not* make find succeed. In other words, even if you `2>/dev/null`, your find will still fail (set a non-zero exit code). This is particularly painful when there is `set -e` in the script that uses find. – foki Nov 21 '21 at 02:25

2 Answers2

8

Because the 'permission denied' message is printed in stderr not stdout.

1 is stdout

2 is stderr

& specifies that whatever following is a file descriptor not filename

2>&1 redirects stderr to stdout and enables the error message to be piped into the grep command.

If excluding permission denied message is all you need, then this will do it without using grep:

find . -name "filename" 2>/dev/null
Jahid
  • 21,542
  • 10
  • 90
  • 108
  • But if it's printed to stderr, why do I see "find . '/path/to/file : Permission denied' " each time? It seems like it's printing to stdout in this case... – wizurd Jun 15 '15 at 17:57
  • 2
    @wizurd Nope, terminal prints both stderr (in case error) and stdout (in case normal operation)... – Jahid Jun 15 '15 at 17:59
  • 1
    btw, a better solution than `2>/dev/null` is [here](http://stackoverflow.com/a/25234419/1034042) – kaay Feb 17 '16 at 11:46
1

When using pipes you should keep in mind that only the standard output is sent to the input of the other command, that's why you need to redirect the stderr to the stdout and then send the stdout (2>&1). 

 $ grep -v "permission denied"

will show the lines that do NOT contain "permission denied".
this solution works but it's far from optimal.
whenever you want to get rid of the error you shoud send it to /dev/null:

$ command 2> /dev/null

/dev/null is like a blackhole, anything you send there will just be lost.
another use of /dev/null is truncating files(for learning only, there is adequate functions to do that properly) :

   $ cat /dev/null > file

the file will be empty after issuing this command.
you should also note that the first thing the bash do is interpreting redirections for example :

    $ > foobar


will create a file foobar
let's say we want to send the stdout and the stderr of one command to a file:

$ command > file 2>&1

or

        $ command &> file

in the first example, the bash will :
1/redirect the stderr to the stdout
2/ redirect the stdout to file
3/execute command
and that's why :

    $ command 2>&1 >file


won't work as expected.
Sometimes you will want to send the stdout to output.txt and stderr to error.txt :

    $ command > ouput.txt 2> error.txt
Baroudi Safwen
  • 803
  • 6
  • 17