Tag Info

This can happen if the application is writing directly to the TTY instead of STDOUT or STDERR. You can play with this behavior by comparing the 2 examples below ( echo foo ) &>/dev/null ( echo foo > $(tty) ) &>/dev/null Notice the first doesn't show anything, but the second does. That's because we sent the output directly to the tty and ...

A segmentation fault is a signal, if you are not catching this then your program will be terminated and your shell will print this to its stderr (rather than your program's stderr). It is possible for either your program or the shell to take specific actions when this occurs, either by the program catching the signal or your shell trapping the SIGCHILD ...

The reason is because there's two types of output. Normal output (STDOUT) Error output (STDERR) cvs --help prints the help info to STDERR. The pipe (|) is expecting data that was written to STDOUT so that it can be read STDIN. In order to get the help text from STDERR to STDOUT (so that it's readable by the pipe) you need to redirect it. cvs --help ...

The “segmentation fault” message is printed to stderr, but it's the shell's standard error, not the program's standard error. The shell prints this message when it detects that the program has terminated due to a signal. You can silence the message by redirecting stderr around the part of the shell script that runs the program: { ./code; } >&log

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, ...

The order of the redirection is important as they are executed sequentially: >filename 2>&1 stdout (fd 1) will point to filename and afterwards the stderr (fd 2) will point to the the target of stdout in this example filename. That means that both stdout and stderr get redirected to filename 2>&1 >filename Here stderr (fd 2) will point to the target of ...

You are looking for tee. See man tee for details. To combine it with exec, you have to use process substitution. (See man bash for details.) exec &> >(tee log.out) echo "This is stdout" echo "This is stderr" >&2

Where would the error be sent when running file_2? When you type ./file_2 (with said file executable), the system actually runs /bin/sh ./file_2 -- i.e. it's running a new copy of /bin/sh, which is responsible for running the commands in ./file2, and for reporting the errors it finds there, outputting them to stderr. But you've just run that /bin/sh with ...

Ooh, a race condition! There are a few things going on here behind the scenes to produce this effect. First, if a process tries to write to a pipe whose other end has been closed, that process receives a SIGPIPE signal. By default, this ends the process. Why would you want this? If you run cat my_huge_file | head -3, you'll only see the first three ...

This behaviour is caused by the fact that the calculation is done by the shell itself, not by an external command. To redirect the STDERR of the shell, you have to start it with that redirection, but then you lose all your errors. bash 2> /dev/null Or you use a brace group, which I think is a more appropriate solution: { a=$(( val1 / val2 } )); } 2> ...

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 ...