FedoraThis forum is for the discussion of the Fedora Project.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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?
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>).
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 and error).
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.
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'.
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.
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.