Hot answers tagged

28

Check out stderred. It uses LD_PRELOAD to hook to libc's write() calls, colorizing all stderr output going to a terminal. (In red by default.)


27

This is a harder version of Show only stderr on screen but write both stdout and stderr to file. The applications running in the terminal use a single channel to communicate with it; the applications have two output ports, stdout and stderr, but they're both connected to the same channel. You can connect one of them to a different channel, add color to ...


12

The problem is error ouput printed to stderr, so the sed command can't catch the input. The simple solution is: redirecting stderr to stdout. find . -name "openssl" 2>&1 | sed '/Permission denied/d;'


12

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


12

Yes, there is a difference. /home/user/script.sh >> /home/user/stdout_and_error.log 2>&1 This will send both STDOUT and STDERR to /home/user/stdout_and_error.log. /home/user/script.sh 2>&1 >> /home/user/stdout_and_error.log This will send STDOUT to /home/user/stdout_and_error.log, and STDERR to what was previously STDOUT. &...


11

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


11

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


11

When I'm writing shell scripts myself I often find it hard to decide what output and which messages I should present on stderr, or if I should bother at all. Silence is golden. Output nothing if everything is fine. I'd like to know about good practice: When is redirecting some message to stderr called for and reasonable, and when not? The ...


11

To make sure that your application is disassociated from its terminal - so that it will not interfere with foreground commands and will continue to run after you logout - nohup ensures that neither stdin nor stdout nor stderr are a terminal-like device. The documentation describes what actions it takes: If the standard output is a terminal, all output ...


11

You're right; pkill isn't generating the message, bash is.  You suggest that $ ./test1.sh 2> /dev/null is a possible solution.  As UVV points out, the equivalent action from within the script is exec 2> /dev/null This redirects the stderr for the script to /dev/null from this statement until it is changed back.  Clumsy ways of changing it back ...


10

You can use tee http://en.wikipedia.org/wiki/Tee_(command) To pipe only stdout cmd | tee log.txt | less To pipe both stdout and stderr: cmd >>(tee stdout.log) 2>>(tee stderr.log >&2)


9

Colouring user input is difficult because in half the cases, it is output by the terminal driver (with local echo) so in that case, no application running in that terminal may know when the user is going to type text and change the output colour accordingly. Only the pseudo-terminal driver (in the kernel) knows (the terminal emulator (like xterm) sends it ...


9

exec 3>&1 4>&2 >log.txt 2>&1 echo hello echo world exec 1>&3 2>&4 less log.txt I.e.: make file descriptors 3 and 4 copies of the current 1 (stdout) and 2 (stderr), redirect 1 to log.txt and 2 to the same as 1; then perform commands; then restore stdout and stderr from the saved values in file descriptors 3 and 4.


9

I'm not sure why you are trying to use sed to remove permission denied messages from output of find - unless you are trying to learn how to use sed. I would simply run this instead: find . -name "openssl" 2>/dev/null Here, I'm redirecting stderr (file descriptor 2) over to /dev/null (refer to man null). In other words, 2>/dev/null simply discards ...


9

With zsh and with the mult_ios option on (on by default), in: echo hi 2>&1 1>/dev/null | cat The 1> /dev/null | cat is seen as a multiple redirection of echo's stdout. So echo's stdout is now redirected to both /dev/null and a pipe to cat (as if using tee). To cancel that multiple redirection, you can do: echo hi 2>&1 >&- >...


9

The special device /dev/stderr is system-specific, while the file descriptor 2 (not the special device /proc/self/fd/2) is portable. If you want to write non-portable code, those special devices are a good place to start. There are a few systems with /dev/stderr: Linux, of course, and OSX. But OSX has no /proc filesystem, and its /dev/stderr is a link to /...


8

This inconsistency is in fact the first reason in the list of reasons why csh programming is considered harmful. Or what if you just want to throw away stderr and leave stdout alone? Pretty simple operation, eh? cmd 2>/dev/null Works in the Bourne shell. In the csh, you can only make a pitiful attempt like this: (cmd > /dev/tty) &...


7

You can use tee. For example: ls -l / | tee tmp.txt Will print to stdout, and tmp.txt will contain a copy of the output. If you want to include stderr in tmp.txt: ls -l / 2>&1 | tee tmp.txt


7

I think it is because this line No valid EAOPL-handshake + ESSID detected. is probably standard error of the pyrit command, not standard out. Normally, | pipes standard out to the next command, with the standard error written immediately to the terminal. Instead, if you want to pass both standard error and out through the pipe, then you can use |&. i....


7

It works for me with simplified bash script (only stderr): $ cat seg.sh #!/bin/bash echo "Segfault" 1>&2 $ test=`./seg.sh`; echo "x$test" Segfault x $ test=`./seg.sh 2>&1`; echo "x$test" xSegfault $ test=`eval ./seg.sh 2>&1`; echo "x$test" xSegfault The problem in your case is caused by the fact that Segmentation fault (core dumped) ...


6

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


6

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


6

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


6

Add exec &>/dev/null in the beginning of bash script


6

Just write a subshell which sends to stdout and stderr... (echo STDOUT && echo STDERR >&2) For proof that it works: (echo STDOUT && echo STDERR >&2) > STDOUT.txt 2> STDERR.txt This will create files STDOUT.txt and STDERR.txt containing the words STDOUT and STDERR respectively.


6

It's just like running two processes to write to the same file at the same time...bad idea. You wind up with two different open file handles and your data can get garbled (as it does in #3 above). Using syntax #2 is correct; it makes one file handle and points both stderr and stdout to the same place. As for stderr always being printed first, there is no ...


6

Adding to wildcard's answer, stdout is usually buffered (stored in memory to be written out later), while stderr never is (you want error messages to show up, even if the program crashes before writing anything out). So stderr will usually show up earlier.


5

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


5

Yes, exactly that can happen if lines to stdout are long enough. #!/usr/bin/perl use strict; use warnings; for (1..10) { print "START"; print "-" x 100000; print "END\n"; warn "!\n"; } Running: ./writer.pl > out 2>&1 Checking: Open file out in an editor and find stderr ! in between -, not always between END and START This will vary ...


5

It appears that the program is re-writting the various write() functions to detect whether you are printing to file descriptor 2 and then adding the relevant escape codes to make the output red at the terminal. Unfortunately, in shell, when you do something like echo "foo" 1>&2 The function will still be calling write (or some other similar ...



Only top voted, non community-wiki answers of a minimum length are eligible