Redirect all output to file in Bash

Question

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?

Solution 1

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:

foo > allout.txt 2>&1

Note: this works in (ba)sh, check your shell for proper syntax

Solution 2

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:

$command &> /some/file

EDIT: thanks to Zack for pointing out that the above solution is not portable--use instead:

$command > file 2>&1 

If you want to silence the error, do:

$command 2> /dev/null

Solution 3

To get the output on the console AND in a file file.txt for example.

make 2>&1 | tee file.txt

Note: & (in 2>&1) specifies that 1 is not a file name but a file descriptor.

Solution 4

Use this - "require command here" > log_file_name 2>&1

Detail description of redirection operator in Unix/Linux.

The > operator redirects the output usually to a file but it can be to a device. You can also use >> to append.

If you don't specify a number then the standard output stream is assumed but you can also redirect errors

> file redirects stdout to file
1> file redirects stdout to file
2> file redirects stderr to file
&> file redirects stdout and stderr to file

/dev/null is the null device it takes any input you want and throws it away. It can be used to suppress any output.

Solution 5

Credits to osexp2003 and j.a. …

---

Instead of putting:

&>> your_file.log

behind a line in:

crontab -e

I use:

#!/bin/bash
exec &>> your_file.log
…

at the beginning of a BASH script.

Advantage: You have the log definitions within your script. Good for Git etc.

View more solutions

Comments

[shelleybutterfly]

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" :)

[shelleybutterfly]

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"

[Marin Sagovac]

Interesting, when I'm setting to top > stdout.txt 2> stderr.txt it will output on stdout.txt but if is like foo > stdout.txt 2> stderr.txt it will only result on stderr.txt not on stdout.txt (blank file)

[ARH]

seems &> and 2>&! both doing the same thing ?

[zwol]

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.

[zwol]

&> file (aka >& file) is not part of the official POSIX shell spec, but has been added to many Bourne shells as a convenience extension (it originally comes from csh). In a portable shell script (and if you don't need portability, why are you writing a shell script?), use > file 2>&1 only.

[Dustin Griffith]

Change > to >> to append instead of overwrite. Kinda obvious but worth mentioning.

[Jacob Bryan]

This doesn't work if your program sends an error. What should you do when you want even that output into the log file??

[Geremia]

@DustinGriffith So, foo >> allout.txt 2>>&1 or foo >> allout.txt 2>&1?

[Dustin Griffith]

@Geremia This is really easy to test by yourself but I will go ahead and say to use 2>&1.

[Geremia]

@DustinGriffith, Yes, just using 2>&1 does work; I tried it.

[Gábor Bakos]

This is related to the original question, but does not answer it.

[davea0511]

Does not answer, but commonly misunderstood and the first answer in fact suggested that > and >> and | were interchangeable. ie - this was not worth your downvote.

[Lanti]

Can we limit the filesizes of stdout and stderr somehow? I not want to dockerise supervisord for this. It would be nice if it's possible.

[deldev]

the &1 sufix means that the output will be the first parameter of the command, in the case, allout.txt

[RhinoDevel]

Redirection operator in Unix/Linux? Which shell?

[Indrajeet Gour]

this will work in both unix and linux and irrespective of shell we used.

[jcarlos]

it worked for me inside a crontab for scripts in R, Ubuntu 14.

[Lion Lai]

by the way, tee -a file.txt means appends to a file.

[Paolo Benvenuto]

&> is not implemented in sh, so beware with commands executed from cron files, crontabl uses sh to run the commands unless you tell it to use another shell.

[The Bndr]

Keep in mind, that > will create/empty the destination file, before the command executes. This is an problem, if you like to modify the file content. cat longlisting.txt | sort > longlisting.txtwill result in an empty file. In this case better use | tee instead of >

[verboze]

Exactly what I wanted, thanks! In my case, I am not directly executing the script (some wrapper script I don't control is calling it), so I cannot specify the input redirect after the command

[qräbnö]

I was happy to support you. By the way, I'd like to note that the example I'm not using (crontab) doesn't even work because crontab uses SH and not BASH. To get further here, the other answers can help. And if you don't know, &>> /dev/null only works with BASH and redirects both STANDARD_OUT (1) and STANDARD_ERROR (2) to Nirvana (3 is STANDARD_IN). In this particular case, it makes no difference whether you overwrite (&>) or append (&>>).

[Peter Cordes]

Apparently &> is an extension supported by some shells, but not specified by POSIX. Be prepared for it to break in #!/bin/sh scripts if dash is your /bin/sh. In dash, it parses the same as two separate commands: foo &, i.e. running the command in the background with output connected to the shell's stdout (e.g. the terminal), and then separately >output which truncates the output file. The other ones are standard syntax, and all of them work in Bash and Zsh, and other typical interactive shells that modern GNU/Linux distros provide as their default.