903

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?

oguz ismail
  • 1
  • 16
  • 47
  • 69
Rayne
  • 14,247
  • 16
  • 42
  • 59

9 Answers9

1427

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

Op De Cirkel
  • 28,647
  • 6
  • 40
  • 53
  • 12
    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 Jul 13 '11 at 05:33
  • 13
    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" – shelleybutterfly Jul 13 '11 at 05:36
  • 1
    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) – Marin Sagovac Feb 22 '13 at 20:03
  • 5
    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`](http://www.tcl.tk/man/expect5.31/expect.1.html) can. – zwol Aug 10 '13 at 20:47
  • 79
    Change `>` to `>>` to append instead of overwrite. Kinda obvious but worth mentioning. – Dustin Griffith Jul 02 '14 at 14:54
  • This doesn't work if your program sends an error. What should you do when you want even that output into the log file?? – Jacob Bryan Feb 04 '15 at 23:05
  • 8
    @DustinGriffith So, `foo >> allout.txt 2>>&1` or `foo >> allout.txt 2>&1`? – Geremia Feb 28 '15 at 06:46
  • 3
    @Geremia This is really easy to test by yourself but I will go ahead and say to use `2>&1`. – Dustin Griffith Feb 28 '15 at 15:30
  • 2
    @DustinGriffith, Yes, just using `2>&1` does work; I tried it. – Geremia Feb 28 '15 at 19:05
  • 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. – Lanti Jan 21 '16 at 10:27
  • the `&1` sufix means that the output will be the first parameter of the command, in the case, `allout.txt` – deldev Jan 21 '16 at 17:15
  • 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.txt`will result in an empty file. In this case better use `| tee` instead of `> ` – The Bndr Sep 13 '18 at 13:53
188

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
Tripp Kinetics
  • 5,178
  • 2
  • 23
  • 37
Bryan Agee
  • 4,924
  • 3
  • 26
  • 42
  • 1
    seems &> and 2>&! both doing the same thing ? – ARH Mar 18 '13 at 03:23
  • 27
    `&> 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. – zwol Aug 10 '13 at 20:50
  • 4
    &> 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. – Paolo Benvenuto May 30 '18 at 06:41
124

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.

Sagar Jain
  • 7,475
  • 12
  • 47
  • 83
65

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.

Indrajeet Gour
  • 4,020
  • 5
  • 43
  • 70
  • 1
    Redirection operator in Unix/Linux? Which shell? – RhinoDevel May 20 '16 at 14:15
  • 3
    this will work in both unix and linux and irrespective of shell we used. – Indrajeet Gour May 23 '16 at 16:31
  • 1
    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. – Peter Cordes Jan 14 '21 at 12:56
53

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.

Arsen Khachaturyan
  • 7,904
  • 4
  • 42
  • 42
qräbnö
  • 2,722
  • 27
  • 40
  • 1
    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 – verboze Dec 28 '18 at 20:11
  • 1
    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 (`&>>`). – qräbnö Dec 28 '18 at 20:37
21

You can use exec command to redirect all stdout/stderr output of any commands later.

sample script:

exec 2> your_file2 > your_file1
your other commands.....
whoan
  • 8,143
  • 4
  • 39
  • 48
osexp2000
  • 2,910
  • 30
  • 29
18

It might be the standard error. You can redirect it:

... > out.txt 2>&1
HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
Petar Ivanov
  • 91,536
  • 11
  • 82
  • 95
17

Command:

foo >> output.txt 2>&1

appends to the output.txt file, without replacing the content.

ellockie
  • 3,730
  • 6
  • 42
  • 44
7

Use >> to append:

command >> file

whoan
  • 8,143
  • 4
  • 39
  • 48
khushi muhammad
  • 127
  • 1
  • 2
  • 7
    This is related to the original question, but does not answer it. – Gábor Bakos Apr 16 '15 at 10:04
  • 1
    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. – davea0511 May 01 '15 at 22:45