Linux IO redirection

First, Introduction

A few days ago using a Linux memory Detection tool Valgrind, want to redirect the results of the detection to a file, the result is always no content, finally found that the reason for the redirect, it output the information is output to stderr, so I use > file This command is clearly not achieving its purpose.

Second, learning

So decided to review the knowledge of IO redirection, and found the following article.

IO redirection

UNIX had the concept of IO redirection long before DOS copied and bastardised the concept. The UNIX IO redirection concept is fundamental to many of the things so can do with UNIX, and it's quite a well-dev eloped idea, so we'll explore this concept here.

Why does I mention UNIX at all? Well, Linux is a UNIX operating system!

Under UNIX, all programs that run is given three open files when they is started by a shell:

0.	Standard in, or STDIN. This is where the input comes from, and it normally points at your terminal device. To find out what device is your terminal, use the tty(1) command. Note, the after command names on UNIX refers to the sections of the The man pages that the documentation for the (1) command exists in. Can arrange to run any command and pass it input from a file in the following: $ Some-command </path/to/some/file Note, the ' is $ your prompt. Note Also, you can always specify a complete path name for a file. For example: $ grep-i Fred </etc/passwd Would search for the string ' Fred ' in/etc/passwd, regardless of the case of the the characters. But wait for a minute, you object, I always use: $ grep-i FRED/ETC/PASSWD This is true, but can also passes the file in to STDIN, and you'll get different results if you do. Can you see what's the difference is?
1.	Standard out, or STDOUT. This is where the normal output from a program goes. It normally points at your terminal as well, but can redirect it. You can redirect output in the following: $ some-program >/path/to/some/file For example: $ grep-i fred/etc/passwd >/tmp/results
2.	Standard error, or STDERR. This is where the error output from the your program goes. This normally points at your terminal as well, but can redirect it. Why are different output places for standard out and standard error? Well, as you'll see if you come to writing shell scripts, you often does not want error messages cluttering up the Norma L Output from a program.

You'll forgive me for starting the above list at 0, I am sure, when you learn so each of the these IO ' channels ' is repre sented by small numbers, called File Descripters (FDs), which has exactly those numbers. That is, STDIN was FD 0, while STDOUT was FD 1, and STDERR is FD 2.

When the shell runs a, it opens STDIN as FD 0, STDOUT as FD 1, and STDERR as FD 2, and then runs the Progr AM (technically, it almost always does a and then an or one of the fork(2) exec(3) exec?? calls). If you had redirected one of STDIN, STDOUT or STDERR, your shell opens that file as the appropriate FD before running the Program.

Now, what does this all has to does with you, I hear you ask?

Well, there is lots of neat things you can does, but some things to watch out for as well.

A lot of inexperienced UNIX users assume this they can redirect a file into a program and use the same name for Redirectin G The output:

$ Some-program < Mega-important-data-file > Mega-important-data-file

They become very upset after doing the above, especially if that mega-important data file have never been backed up Anywher E. Why are this?

The shell opens the Mega-important-data-file for reading and associates it has FD 0 (or STDIN), and then opens it for WRI Ting, but truncates it-zero length, and associates it with FD 1 (or STDOUT) as well.

So, if you want to does something like the above, use a different file name for the output file. Oh, you should also back up files as well:-).

Now, there is lots of redirection symbols that's can use, and here is some of them:

<  file	means open a file for reading and associate with STDIN .
<<  token	Means Use the current input stream as STDIN for the program until  token  is seen. We'll ignore this one until we get to scripting.
>  file	means open a file for writing and truncate it and ASSOCI Ate it with STDOUT.
>>  file	means open a file for writing and seek to the end an D Associate it with STDOUT. Append to a file using a redirect.
n >& m	means redirect fd  n  to the same Places as fd  m . eg,  2>&1  means send STDERR to the same place that STDOUT are going to.

OK, here is some tricks that's might want to use in various places.

If you is gathering evidence for a bug report, you might want to redirect the output from a series of programs to a text File (Never mind, the can use the script command to do the same:-). Might do the following:

some-params >> important-evidence.txt

The second and subsequent lines append the output from the commands issues to the evidence file rather than th Em. Try the following:

$ echo This was a line of the text >/tmp/file.txt$ echo this was another line   >/tmp/file.txt

What does you get?

Now try:

$ echo This was a line of the text >/tmp/file.txt$ echo this was another line   >>/tmp/file.txt

What does the get this time?

OK, for the last few tricks here. Sometimes want to append STDOUT and STDERR to a file. How does it?

$ some-command >>/tmp/log.log 2>&1

The says make STDERR point to the 2>&1 same places as STDOUT. Since STDOUT is open already, and the shell have done a seek to the end, STDERR would also be appended to STDOUT.

If you want to append a line to a file, you can echo the line want with a redirect, rather than firing up an editor:

Some text >>/path/to/some/file

It turns out this you can cause the shell to redirect to other file descriptors as well, and if your look in the Configure Scripts that come with many UNIX software packages, you'll see examples of this.

Why are redirecting so important? Well, it's used in many shell scripts, it's a simple and conventient mechanism to sending output to any file without the Programmer has to add code for handling command line instructions, and it is the UNIX-from-doing things:-).

It is also the same as piping, where you redirect output to, or input from, a pipe device. The pipe device has a process living on the other side, but we'll look in this later.

Linux IO redirection