How to save output or errors to a file with Linux shell redirection
A running program, or process, needs to read input from somewhere and write output to somewhere. A command run from the shell prompt normally reads its input from the keyboard and sends its output to its terminal window.
A process uses numbered channels called file descriptors to get input and send output. All processes start with at least three file descriptors. Standard input (channel 0) reads input from the keyboard. Standard output (channel 1) sends normal output to the terminal. Standard error (channel 2) sends error messages to the terminal. If a program opens separate connections to other files, it may use higher-numbered file descriptors.
| NUMBER | CHANNEL NAME | DESCRIPTION | DEFAULT CONNECTION | USAGE |
|---|---|---|---|---|
| 0 | stdin | Standard input | Keyboard | read only |
| 1 | stdout | Standard output | Terminal | write only |
| 2 | stderr | Standard error | Terminal | write only |
| 3+ | filename | Other files | none | read and/or write |
Redirecting output to a file
I/O redirection changes how the process gets its input or output. Instead of getting input from the keyboard, or sending output and errors to the terminal, the process reads from or writes to files. Redirection lets you save messages to a file that are normally sent to the terminal window. Alternatively, you can use redirection to discard output or errors, so they are not displayed on the terminal or saved.
Redirecting stdout suppresses process output from appearing on the terminal. As seen in the following table, redirecting only stdout does not suppress stderr error messages from displaying on the terminal. If the file does not exist, it will be created. If the file does exist and the redirection is not one that appends to the file, the file’s contents will be overwritten. If you want to discard messages, the special file /dev/null quietly discards channel output redirected to it and is always an empty file.
| USAGE | EXPLANATION |
|---|---|
| > file | redirect stdout to overwrite a file |
| » file | redirect stdout to append to a file |
| 2> file | redirect stderr to overwrite a file |
| 2> /dev/null | discard stderr error messages by redirecting to /dev/null |
| > file 2>&1 | redirect stdout and stderr to overwrite the same file |
| » file 2>&1 | redirect stdout and stderr to append to the same file |
Note: The order of redirection operations is important. The following sequence redirects standard output to file and then redirects standard error to the same place as standard output (file).
However, the next sequence does redirection in the opposite order. This redirects standard error to the default place for standard output (the terminal window, so no change) and then redirects only standard output to file.
Because of this, some people prefer to use the merging redirection operators:
&>file instead of >file 2>&1 &>>file instead of >>file 2>&1 (in Bash 4) However, other system administrators and programmers who also use other shells related to bash (known as Bourne-compatible shells) for scripting commands think that the newer merging redirection operators should be avoided, because they are not standardized or implemented in all of those shells and have other limitations.
Examples for Output Redirection
Many routine administration tasks are simplified by using redirection. Use the previous table to assist while considering the following examples:
1. Save a time stamp for later reference.
2. Copy the last 100 lines from a log file to another file.
[[email protected] ~]$ tail -n 100 /var/log/dmesg > /tmp/last-100-boot-messages 3. Concatenate four files into one.
[user@host ~]$ cat file1 file2 file3 file4 > /tmp/all-four-in-one 4. List the home directory’s hidden and regular file names into a file.
5. Append output to an existing file.
[[email protected] ~]$ echo "new line of information" >> /tmp/many-lines-of-information [[email protected] ~]$ diff previous-file current-file >> /tmp/tracking-changes-made 6. The next few commands generate error messages because some system directories are inaccessible to normal users. Observe as the error messages are redirected. Redirect errors to a file while viewing normal command output on the terminal.
[[email protected] ~]$ find /etc -name passwd 2> /tmp/errors 7. Save process output and error messages to separate files.
[[email protected] ~]$ find /etc -name passwd > /tmp/output 2> /tmp/errors 8. Ignore and discard error messages.
[[email protected] ~]$ find /etc -name passwd > /tmp/output 2> /dev/null 9. Store output and generated errors together.
[[email protected] ~]$ find /etc -name passwd &> /tmp/save-both 10. Append output and generated errors to an existing file.
[[email protected] ~]$ find /etc -name passwd >> /tmp/save-both 2>&1 How to redirect error to a file?
Now, lets suppose I change date=$(date) to date= $(date) which will generate an error. My modified script:
filename="/home/ronnie/tmp/hello" date= $(date) echo "$date" >> $filename 2>> $filename #Also tried echo "$date" >> $filename 2>&1 I was thinking that above script will redirect the error test.sh: line 5: Fri: command not found to the file hello but it just enters a new line into the file and the error gets printed on my stdout . My bash version:
ronnier@ronnie:~/tmp$ bash --version GNU bash, version 4.2.24(1)-release (i686-pc-linux-gnu) 2 Answers 2
The line which causes the error is date =$(date) , that error is sent to stderr. At that stage, you’re not redirecting stderr anywhere. The subsequent line sends stderr to $filename, but it’s not that line which causes the error.
One of the ways to get the effect you want, you would run your script and direct stderr to somewhere else at the same time, so,
at that point, errors.txt will contain your error.
So the issue is, the line generating the error is an error in the script itself, not an error caused by an external command the script calls which has it’s output redirected. i.e. it’s the top level script output you need to redirect.
Another strategy would be to surround several lines in your script with <. >2>> errors.txt or (. ) 2>> errors.txt . The second is less efficient but behaves in ways that are useful in certain circumstances. (Read about «subshells» to learn more.)
The shell emits an error message when it reaches line 5. The shell’s error stream is not redirected at this point.
If you write date= $(date) 2>/dev/null , the “command not found” message comes from the shell, not from the command whose error stream is redirected. Therefore you’ll still see the error message.
To avoid seeing the error message, put the whole command inside a group and redirect the error stream from the whole group:
With braces, the command is still executed in the parent shell, so it can change its environment and other state (not that it does here). You can also put the command in a function body, or in a subshell (commands inside parentheses, which are executed in a separate shell process).
You can redirect the file descriptors of the shell permanently (or at least until the next time you change them) by using a redirection on the exec builtin with no command name.
exec 2>/dev/null # From this point on, all error messages are lost date= $(date) … exec 2>/some/log/file # From this point on, all error messages go to the specified file Redirect all output to file in Bash [duplicate]
I know that in Linux, to redirect output from the screen to a file, I can either use the > or tee . However, I’m not sure why part of the output is still output to the screen and not written to the file. Is there a way to redirect all output to file?
9 Answers 9
That part is written to stderr, use 2> to redirect it. For example:
foo > stdout.txt 2> stderr.txt or if you want in same file:
Note: this works in (ba)sh, check your shell for proper syntax
well, i found the reference and have deleted my post for having incorrect information. from the bash manual: ‘»ls 2>&1 > dirlist» directs only the standard output to dirlist, because the standard error was duplicated from the standard output before the standard output was redirected to dirlist» 🙂
also from the bash man «There are two formats for redirecting standard output and standard error: &>word and >&word Of the two forms, the first is preferred. This is semantically equivalent to >word 2>&1»
Two important addenda: If you want to pipe both stdout and stderr, you have to write the redirections in the opposite order from what works for files, cmd1 2>&1 | cmd2 ; putting the 2>&1 after the | will redirect stderr for cmd2 instead. If both stdout and stderr are redirected, a program can still access the terminal (if any) by opening /dev/tty ; this is normally done only for password prompts (e.g. by ssh ). If you need to redirect that too, the shell cannot help you, but expect can.
All POSIX operating systems have 3 streams: stdin, stdout, and stderr. stdin is the input, which can accept the stdout or stderr. stdout is the primary output, which is redirected with > , >> , or | . stderr is the error output, which is handled separately so that any exceptions do not get passed to a command or written to a file that it might break; normally, this is sent to a log of some kind, or dumped directly, even when the stdout is redirected. To redirect both to the same place, use:
EDIT: thanks to Zack for pointing out that the above solution is not portable—use instead:
If you want to silence the error, do: