A common idiom to ignore error output from commands is to discard it by directing it to the special /dev/null device file, which just ignores anything written to it and is always empty:

$ grep pattern myfile /nonexistent > matches 2> /dev/null

If you want to ignore error output, this works, but think carefully before you do this. Error messages are written to let you know and to help you understand when something is not working, and they assist in debugging, especially when the error isn't fatal – that is, when the command still runs to completion and maybe generates some output, so if nobody sees the errors, it might seem like everything is working fine.

A good example is the comm tool, which shows lines that differ between files, similar to diff, except it requires its input files to be sorted to do its efficient comparison. If they're not sorted the way it expects, it raises an error like this:

$ comm myfile1 myfile2
comm: file 1 is not in sorted order

This warning is to alert the user that the program actually cannot do its work correctly if the files are not sorted. If you suppress the error completely, and don't log it anywhere, it makes it much harder to debug later:

$ comm myfile1 myfile2 2> /dev/null
$ echo $?
1

We can see the comm command exited non-zero, meaning there was an error. What was the error? We can't tell, because we blocked it! This is particularly painful in automated scripts: nobody ever sees the error, so it could be a long time before anyone actually notices things are broken.

Instead, you may be able to adjust your script so that the error condition does not arise at all, or perhaps pass program-specific options (often -f or -q) to suppress errors selectively, instead of just discarding any and all error output.

Another method is to write the error output to a file, in case you do need to check it later:

$ grep pattern myfile /nonexistent > matches 2>> errorlog