Tag Info

Hot answers tagged

26

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


25

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

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


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

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;'


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

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


10

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


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

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


8

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


8

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.


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


7

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


6

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


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


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

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


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

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


5

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.


5

I don't think it's got anything to do with nohup. You get the same behavior when you do python a.py > a.log 2>&1. Python is most likely using C file stdio underneath. With that, stdout, when in a terminal, will be line-buffered, and buffered when stdout is a file. stderr is always unbuffered. Redirecting stdout to a file will switch stdout's ...


4

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


4

Here's a proof of concept I did a while back. It only works in zsh. # make standard error red rederr() { while read -r line do setcolor $errorcolor echo "$line" setcolor normal done } errorcolor=red errfifo=${TMPDIR:-/tmp}/errfifo.$$ mkfifo $errfifo # to silence the line telling us what job number the background job is ...


4

There are three standard files open for each program, stdin (standard input), stdout(standard output), and stderr (standard error). Writes to both stdout and stderr is output in the terminal by default. It is a common convention to write errors and log messages to stderr instead of stdout in order to not mix log or error messages with actual program output. ...


4

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


4

{ readlink /dev/fd/[1,2] ; echo "out" ; } >./file 2>./error { readlink /dev/fd/0 ; cat ; } <./file OUTPUT: /home/mikeserv/file /home/mikeserv/file /home/mikeserv/error out { readlink /proc/$$/fd/[1,2] ; echo out ; } >./file 2>./error { readlink /proc/$$/fd/0 ; cat ; } <./file OUTPUT: /home/mikeserv/file /home/mikeserv/file ...


4

On the first command line, the shell sees >> file first and append stdout to file . Next 2>&1 sends fd2 ( stderr ) to the same place fd1 is going - that's to the file. And that's what you want. On the second command line, the shell sees 2>&1 first. That means "make the standard error (file descriptor 2) go to the same place as the standard output (fd1) is ...


4

I don't think you can get around that. With -tt, sshd spawns a pseudo-terminal and makes the slave part the stdin, stdout and stderr of the shell that executes the remote command. sshd reads what's coming from its (single) fd to the master part of the pseudo-terminal and sends that (via one single channel) to the ssh client. There is no second channel for ...



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