1788

To redirect standard output to a truncated file in Bash, I know to use:

cmd > file.txt

To redirect standard output in Bash, appending to a file, I know to use:

cmd >> file.txt

To redirect both standard output and standard error to a truncated file, I know to use:

cmd &> file.txt

How do I redirect both standard output and standard error appending to a file? cmd &>> file.txt did not work for me.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
flybywire
  • 247,088
  • 187
  • 391
  • 495
  • 48
    I would like to note that &>outfile is a Bash (and others) specific code and not portable. The way to go portable (similar to the appending answers) always was and still is >outfile 2>&1 – TheBonsai May 18 '09 at 04:48
  • 4
    … and ordering of that is important. – Torsten Bronger Jun 19 '20 at 12:08
  • Does this answer your question? [Redirect stderr and stdout in Bash](https://stackoverflow.com/questions/637827/redirect-stderr-and-stdout-in-bash) – Brett Hale Aug 12 '21 at 06:58
  • @BrettHale I marked that one as a duplicate of this question instead, mainly because the accepted answer here is portable to other shells, and this question is better articulated. Weird that the same user asked the same question twice, and didn't get noticed until now. – tripleee Aug 12 '21 at 07:24

9 Answers9

2312
cmd >>file.txt 2>&1

Bash executes the redirects from left to right as follows:

  1. >>file.txt: Open file.txt in append mode and redirect stdout there.
  2. 2>&1: Redirect stderr to "where stdout is currently going". In this case, that is a file opened in append mode. In other words, the &1 reuses the file descriptor which stdout currently uses.
Fritz
  • 1,034
  • 14
  • 27
Alex Martelli
  • 811,175
  • 162
  • 1,198
  • 1,373
  • 35
    works great! but is there a way to make sense of this or should I treat this like an atomic bash construct? – flybywire May 18 '09 at 08:15
  • 189
    It's simple redirection, redirection statements are evaluated, as always, from left to right. >>file : Red. STDOUT to file (append mode) (short for 1>>file) 2>&1 : Red. STDERR to "where stdout goes" Note that the interpretion "redirect STDERR to STDOUT" is wrong. – TheBonsai May 18 '09 at 08:55
  • 31
    It says "append output (stdout, file descriptor 1) onto file.txt and send stderr (file descriptor 2) to the same place as fd1". – Dennis Williamson May 18 '09 at 09:07
  • 2
    @TheBonsai however what if I need to redirect STDERR to another file but appending? is this possible? – arod Jun 02 '13 at 22:26
  • 43
    if you do `cmd >>file1 2>>file2` it should achieve what you want. – Woodrow Douglass Sep 06 '13 at 21:24
  • if pipe is what you want, try `cmd1 |& cmd2`. It works in bash v4+. – jpbochi Jan 16 '20 at 17:11
  • 1
    Just to emphasize this to users like myself: the order of the redirect matters, 2>&1 should be after >>file.txt. – CodeBrew Jul 23 '20 at 18:27
  • 1
    I have file1.txt and file2.txt in currect directory. When I run: 1. ls file{1..5}.txt 1>res.txt 2>&1: it gives correct output to res.txt But when I write 2. ls file{1..5}.txt 1>res.txt 2>res.txt: now it doesn't give correct output to res.txt, here in res.txt some output is omitted compare to what it should've been if we weren't redirect any stream. Why ? – tusharRawat Aug 04 '20 at 16:08
418

There are two ways to do this, depending on your Bash version.

The classic and portable (Bash pre-4) way is:

cmd >> outfile 2>&1

A nonportable way, starting with Bash 4 is

cmd &>> outfile

(analog to &> outfile)

For good coding style, you should

  • decide if portability is a concern (then use the classic way)
  • decide if portability even to Bash pre-4 is a concern (then use the classic way)
  • no matter which syntax you use, don't change it within the same script (confusion!)

If your script already starts with #!/bin/sh (no matter if intended or not), then the Bash 4 solution, and in general any Bash-specific code, is not the way to go.

Also remember that Bash 4 &>> is just shorter syntax — it does not introduce any new functionality or anything like that.

The syntax is (beside other redirection syntax) described in the Bash hackers wiki.

Matthias Braun
  • 28,341
  • 18
  • 134
  • 157
TheBonsai
  • 13,975
  • 4
  • 21
  • 14
  • 8
    I prefer &>> as it's consistent with &> and >>. It's also easier to read 'append output and errors to this file' than 'send errors to output, append output to this file'. Note while Linux generally has a current version of bash, OS X, at the time of writing, still requires bash 4 to manually installed via homebrew etc. – mikemaccana May 20 '13 at 09:30
  • I like it more because it is shorter and only tweoi places per line, so what would for example zsh make out of "&>>"? – Phillipp Feb 17 '16 at 14:20
  • Also important to note, that in a cron job, you have to use the pre-4 syntax, even if your system has Bash 4. – hyperknot May 18 '17 at 10:03
  • 5
    @zsero cron doesn't use bash at all... it uses `sh`. You can change the default shell by prepending `SHELL=/bin/bash` to the `crontab -e` file. – Ray Foss Jun 05 '18 at 20:45
105

In Bash you can also explicitly specify your redirects to different files:

cmd >log.out 2>log_error.out

Appending would be:

cmd >>log.out 2>>log_error.out
Aaron R.
  • 3,184
  • 3
  • 15
  • 19
  • 8
    Redirecting two streams to the same file using your first option will cause the first one to write "on top" of the second, overwriting some or all of the contents. Use ***cmd >> log.out 2> log.out*** instead. – Orestis P. Dec 11 '15 at 14:33
  • 4
    Thanks for catching that; you're right, one will clobber the other. However, your command doesn't work either. I think the only way to write to the same file is as has been given before `cmd >log.out 2>&1`. I'm editing my answer to remove the first example. – Aaron R. Dec 11 '15 at 15:36
  • 1
    The reason `cmd > my.log 2> my.log` doesn't work is that the redirects are evaluated from left to right and `> my.log` says "create new file `my.log` replacing existing files and redirect `stdout` to that file" and *after* that has been already done, the `2> my.log` is evaluated and it says "create new file `my.log` replacing existing files and redirect `stderr` to that file". As UNIX allows deleting open files, the stdout is now logged to file that used to be called `my.log` but has since been deleted. Once the last filehandle to that file is closed, the file *contents* will be also deleted. – Mikko Rantalainen Jul 08 '21 at 07:32
  • 1
    On the other hand, `cmd > my.log 2>&1` works because `> my.log` says "create new file `my.log` replacing existing files and redirect `stdout` to that file" and after that has been already done, the `2>&1` says "point file handle 2 to file handle 1". And according to POSIX rules, file handle 1 is always stdout and 2 is always stderr so `stderr` then points to already opened file `my.log` from first redirect. Notice that syntax `>&` doesn't create or modify actual files so there's no need for `>>&`. (If *first* redirect had been `>> my.log` then file had been simply opened in append mode.) – Mikko Rantalainen Jul 08 '21 at 07:40
77

This should work fine:

your_command 2>&1 | tee -a file.txt

It will store all logs in file.txt as well as dump them in the terminal.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Pradeep Goswami
  • 1,605
  • 1
  • 14
  • 22
69

In Bash 4 (as well as Z shell (zsh) 4.3.11):

cmd &>> outfile

just out of box.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
A B
  • 1,926
  • 2
  • 20
  • 22
  • 2
    @all: this is a good answer, since it works with bash and is brief, so I've edited to make sure it mentions bash explicitly. – mikemaccana May 20 '13 at 08:47
  • 10
    @mikemaccana: [TheBonsai's answer](http://stackoverflow.com/a/876267/4279) shows bash 4 solution since 2009 – jfs Mar 27 '14 at 17:56
  • 1
    Why does this answer even exist when it's included in TheBonsai's answer? Please consider deleting it. You'll get a [disciplined badge](https://meta.stackexchange.com/questions/7609/what-is-the-purpose-of-the-disciplined-badge). – Dan Dascalescu Jun 14 '21 at 06:23
29

Try this:

You_command 1> output.log  2>&1

Your usage of &> x.file does work in Bash 4. Sorry for that: (

Here comes some additional tips.

0, 1, 2, ..., 9 are file descriptors in bash.

0 stands for standard input, 1 stands for standard output, 2 stands for standard error. 3~9 is spare for any other temporary usage.

Any file descriptor can be redirected to other file descriptor or file by using operator > or >>(append).

Usage: <file_descriptor> > <filename | &file_descriptor>

Please see the reference in Chapter 20. I/O Redirection.

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Quintus.Zhou
  • 923
  • 9
  • 13
  • 1
    Your example will do something different than the OP asked for: It will redirect the stderr of `You_command` to stdout and the stdout of `You_command` to the file `output.log`. Additionally it will not append to the file but it will overwrite it. – pabouk - Ukraine stay strong May 31 '14 at 12:38
  • 1
    Correct: ***File descriptor*** could be any values which is more than 3 for all other files. – Itachi Dec 25 '14 at 06:46
  • 7
    Your answer shows the most common output redirection error: redirecting STDERR to where STDOUT is currently pointing and only after that redirecting STDOUT to file. This will not cause STDERR to be redirected to the same file. Order of the redirections matters. – Jan Wikholm Jan 04 '15 at 12:51
  • 2
    does it mean, i should firstly redirect STDERROR to STDOUT, then redirect STDOUT to a file. `1 > output.log 2>&1` – Quintus.Zhou Mar 04 '15 at 06:10
  • 2
    @Quintus.Zhou Yup. Your version redirects err to out, and at the same time out to file. – Alex Yaroshevich Mar 08 '15 at 23:22
  • Re *"does work in..."*: Do you mean *"does* ***not*** *work in..."* (the opposite)? – Peter Mortensen Aug 16 '21 at 11:24
15

Another approach:

If using older versions of Bash where &>> isn't available, you also can do:

(cmd 2>&1) >> file.txt

This spawns a subshell, so it's less efficient than the traditional approach of cmd >> file.txt 2>&1, and it consequently won't work for commands that need to modify the current shell (e.g. cd, pushd), but this approach feels more natural and understandable to me:

  1. Redirect standard error to standard output.
  2. Redirect the new standard output by appending to a file.

Also, the parentheses remove any ambiguity of order, especially if you want to pipe standard output and standard error to another command instead.

To avoid starting a subshell, you instead could use curly braces instead of parentheses to create a group command:

{ cmd 2>&1; } >> file.txt

(Note that a semicolon (or newline) is required to terminate the group command.)

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
jamesdlin
  • 65,531
  • 13
  • 129
  • 158
  • 1
    This implementation causes one extra process for system to run. Using syntax `cmd >> file 2>&1` works in all shells and does not need an extra process to run. – Mikko Rantalainen Apr 15 '20 at 08:06
  • 1
    @MikkoRantalainen I already explained that it spawns a subshell and is less efficient. The point of this approach is that if efficiency isn't a big deal (and it rarely is), this way is easier to remember and harder to get wrong. – jamesdlin Apr 15 '20 at 09:21
  • 2
    @MikkoRantalainen I've updated my answer with a variant that avoids spawning a subshell. – jamesdlin Jun 28 '20 at 04:13
  • If you truly cannot remember if the syntax is `cmd >> file 2>&1` or `cmd 2>&1 >> file` I think it would be easier to do `cmd 2>&1 | cat >> file` instead of using braces or parenthesis. For me, once you understand that the implementation of `cmd >> file 2>&1` is literally "redirect STDOUT to `file`" followed by "redirect STDERR to whatever *file* STDOUT is currently pointing to" (which is obviously `file` after the first redirect), it's immediately obvious which order you put the redirects. UNIX does not support redirecting to a stream, only to *file* descriptor pointed by a stream. – Mikko Rantalainen Jun 29 '20 at 06:58
9

Redirections from script himself

You could plan redirections from the script itself:

#!/bin/bash

exec 1>>logfile.txt
exec 2>&1

/bin/ls -ld /tmp /tnt

Running this will create/append logfile.txt, containing:

/bin/ls: cannot access '/tnt': No such file or directory
drwxrwxrwt 2 root root 4096 Apr  5 11:20 /tmp

Log to many different files

You could create two different logfiles, appending to one overall log and recreating another last log:

#!/bin/bash

if [ -e last.log ] ;then
    mv -f last.log last.old
fi
exec 1> >(tee -a overall.log /dev/tty >last.log)
exec 2>&1

ls -ld /tnt /tmp

Running this script will

  • if last.log already exist, rename them to last.old (overwriting last.old if they exist).
  • create a new last.log.
  • append everything to overall.log
  • output everything to the terminal.

Simple and combined logs

#!/bin/bash

[ -e last.err ] && mv -f last.err lasterr.old
[ -e last.log ] && mv -f last.log lastlog.old

exec 2> >(tee -a overall.err combined.log /dev/tty >last.err)
exec 1> >(tee -a overall.log combined.log /dev/tty >last.log)

ls -ld /tnt /tmp

So you have

  • last.log last run log file
  • last.err last run error file
  • lastlog.old previous run log file
  • lasterr.old previous run error file
  • overall.log appended overall log file
  • overall.err appended overall error file
  • combined.log appended overall error and log combined file.
  • still output to the terminal

And for interactive session, use stdbuf:

If you plan to use this in interactive shell, you must tell tee to not buffering his input/output:

# Source this to multi-log your session
[ -e last.err ] && mv -f last.err lasterr.old
[ -e last.log ] && mv -f last.log lastlog.old
exec 2> >(exec stdbuf -i0 -o0 tee -a overall.err combined.log /dev/tty >last.err)
exec 1> >(exec stdbuf -i0 -o0 tee -a overall.log combined.log /dev/tty >last.log)

Once sourced this, you could try:

ls -ld /tnt /tmp
F. Hauri
  • 58,205
  • 15
  • 105
  • 122
  • See further: [Pipe output to two different commands](https://stackoverflow.com/a/13108173/1765658), then follow link to *more detailled answer on this duplicate* in [comment](https://stackoverflow.com/questions/13107783/pipe-output-to-two-different-commands/13108173#comment47763415_13108173). – F. Hauri Nov 11 '21 at 18:14
0

If you care about the ordering of the content of the two streams, see @ed-morton 's answer to a similar question, here.

Ana Nimbus
  • 565
  • 2
  • 15