Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
I don't quite understand how the computer reads this command.
cat file1 file2 1> file.txt 2>&1
If I understand, 2>&1 simply redirect Standard Error to Standard Output.
By that logic, the command reads to me as follows:
concatenate files file1 and file2.
send stdout from this operation to file.txt.
send stderr to stdout.
end?
I'm not sure what the computer's doing. By my logic, the command should be
cat file1 file2 2>&1 > file.txt
but this is not correct.
I find it easier to think of using assignments.
> is like =& is like $You start out with
1 = /dev/tty
2 = /dev/tty
then your first example, 1> file.txt 2>&1, does
1 = file.txt
2 = $1 # and currently $1 = file.txt
leaving you with
1 = file.txt
2 = file.txt
If you did it the other way, again you start with
1 = /dev/tty
2 = /dev/tty
then 2>&1 > file.txt does
2 = $1 # and currently $1 = /dev/tty
1 = file.txt
so the end result is
1 = file.txt
2 = /dev/tty
and you've only redirected stdout, not stderr.
$ stand for?
Jun 24, 2019 at 14:28
var=$othervar, $ introduces the variable name on the right hand side. In a redirection like 2>&1, & introduces the file descriptor number on the right hand side. I'm saying you can think of it like "file 2 equals file 1". (But there are two types of equals: < means "for reading" and > means "for writing".)
1 or 2 you understand the difference between 2>1 and 2>&1 per @Mikel Also, I appreciate the mental translation, it works for me. 1>&2 becomes 1 = $2 which syntactically "sort of" means something in bash, RegEx, and probably Perl.
The order of redirection is important, and they should be read left to right.
For example:
command 2>&1 >somefile means:
2 (bound to stderr) to the current destination of 1 (stdout) which at this point, reading left-ot-right is the terminal. 1 (stdout) to go to somefile, which is a a file in disk So in this case, stderr goes to the terminal, and stdout goes to a file, which isn't what you probably want.
On the other hand, command >somefile 2>&1 means:
stdout to somefilestderr to the same destination as stdout (somefile). In this last case both stderr and stdout go to somefile, which is probably what you want.
cat file1 file2 1> file.txt 2>&1
>& Actually means duplicate, it uses the dup system call to to map a new file descriptor onto an already opened file.
So, you (bash actually) must first open the new stdout before, saying " and redirect stderr to whatever stdout is currently set."
&. could you enclose some references to that syntax, or - better yet - some good resources on the aforementioned dup system?
Jun 24, 2019 at 14:59
man dup. The thing being duplicated is the file descriptor, in C dup2(1, 2); will make fd2 (stderr) a copy of (duplicate) of fd1 (stdout)
The command cat file1 file2 > file.txt 2>&1 sends both stdout and stderr of the cat command to file.txt. Now, this is only useful if somehow either file1 or file2 are not found, in which case error message saying 'file not found' will be saved to file.txt.
This is the same as cat file1 file2 &> file.txt.
Now the order of redirections matter. The following doesn't send stderr of cat command to file.txt but to the terminal.
$ cat file1 file2 2>&1 > file.txt
This is because it is first copying the destination of stdout to stderr, but stdout at this stage is still pointing to the terminal. Then you redirected stdout to file.txt, so only stdout will be saved to file.txt. Error messages will still be printed to the screen and not saved to file.txt.
