What does "2>" do when added to "find" command?

O(V)eGA_l2el) · 08-05-2007, 08:36 AM

Utilizing: 2.6.20-*.fc6

Command:
find / -name rc.local 2>/dev/null

I understand that without 2>/dev/null, the find command would display every directory while searching for rc.local. With 2>/dev/null, only the directories containing rc.local would be displayed (which is my preferred method). What I do not understand is what the 2> does? Will someone explain to me?

raskin · 08-05-2007, 08:40 AM

2> redirects 'standard error output'. Usually when a tool wants to has something as its 'official output' (like for piping) and something to be 'information for user' which is displayed even when output is piped, it will write output to descriptor 1 (stdout, redirected by 1> or just > ) and information to descriptor 2 (stderr, redirected by 2>).

paul_one · 08-05-2007, 02:01 PM

When you type a command at a terminal (command prompt, command line interface, whatever you call it) it's output is displayed to you.

This is not actually one output but rather a culmination of different 'channels' all together.
The standards are : std.in, std.out and std.err (in, out[1] and error[2]).

1 is used for output to the user. This contains results etc.
2 is used for errors, redirecting this in find is good for scripts, especially when it is just complaining about not being able to access directories.

3 and above are rarely used, but I have seen 3 and 4 used before.

The 2> redirects the output from this stream and pipes it into a location.. This can be another stream ( 2>&1 ) or (usually) a filesystem location... /dev/null to basically ignore the output from this stream, or /tmp/check_later which means you can open that file later and check the output.

raskin · 08-05-2007, 02:13 PM

Well, if we are to go into these details, it is reasonable to mention also that the same 'channels' are used for file I/O and that program expects stdout and stderr to exist and somehow accept output. Talking about higher 'channel numbers' program usually assumes they do not exist on its start and creates them by identifying with some files or channels. Even if you redirect 'channel 3' by 3> it is highly probable that a program will either reassign it to whatever it wants (as it does not consider it to be pointing to anything reasonable), silently use next free number, or even fail - but not redirect what it would normally write to this 'channel'.

paul_one · 08-05-2007, 02:21 PM

Oh right. That's good to know.

Are they actually called channels? I can't remember, but something's bugging me about what they're called.
Seeing what you've written above, channels seems a more appropriate name to call them.

raskin · 08-05-2007, 02:38 PM

No, they are really called 'file descriptors'. I just liked your description (which reflects their use), and decided to make additions to it. They are also one of a few types of objects that are usually wrapped in something called 'streams' in high-level languages. When you create a new pair of file descriptors just to serve to take data from one process and give it to another, it is called 'pipe'.

File descriptor is generally an index in the array of open file-like objects kept for this process by OS.

Usually programs create file descriptors (by opening files) before using them, but standard requires to have descriptors 1 and 2 already open when a program starts. File descriptor 0 is also open, and it is standard input.

paul_one · 08-05-2007, 04:04 PM

Sorry, I keep mixing descriptions all over the place. Channels was a throw-back to what I remember from basic and the good old sinclair QL.

My original reason for posting was that although you gave good info - I think it wasn't enough for that person (who I guess was looking in a script and saw that in a line) who may not have known what std.err or std.out were and what you meant exactly.

Thanks for expanding on the names.

Robhogg · 08-05-2007, 04:22 PM

To put it a different way, ...2>/dev/null is a way of preventing the results that you want being drowned in error messages.

I usually use it when searching as an ordinary user, as without root permissions, find will usually throw up a flood of "Permission denied" errors if searching through system directories.

Yours helpfully,
Rob

Edit: an example:
With:

Code:

bertie@mylinux:~$ find / -name bash 2>/dev/null
/bin/bash
/usr/share/doc/bash
/usr/share/menu/bash
/media/hdc4/bin/bash
/media/hdc4/usr/share/doc/packages/bash
bertie@mylinux:~$

... and without:

Code:

bertie@mylinux:~$ find / -name bash
/bin/bash
find: /etc/ssl/private: Permission denied
find: /etc/cups/ssl: Permission denied
find: /etc/firestarter/outbound: Permission denied
find: /etc/firestarter/inbound: Permission denied
find: /var/lib/gdm: Permission denied
find: /var/lib/slocate: Permission denied
find: /var/run/cups/certs: Permission denied
find: /var/tmp/kdecache-root: Permission denied
find: /var/cache/setup-tool-backends/debug: Permission denied
find: /var/cache/setup-tool-backends/backup: Permission denied
find: /var/spool/cron/atjobs: Permission denied
find: /var/spool/cron/atspool: Permission denied
... 
227 lines in total!

syg00 · 08-06-2007, 02:25 AM

"man bash" - search for REDIRECTION