Tag Info

Hot answers tagged

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

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


10

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


10

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


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

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


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

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


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


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


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

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


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.


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

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

{ 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

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


4

A simple approach would be to use ls to list actual and imaginary files: ls . *.blah This assumes that there are visible files in the working directory and that you don't have any files that end in .blah1 1. ...and if you do, we won't judge you.


4

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


4

That software hooks the write() system calls that apprear to write at file descriptor 2, that is known as stderr. It is a shared library (so recompilation of the kernel is not necessary). As descripted in the installation manual it takes use of the environment varaible LD_PRELOAD. The dynamic linker can be influenced into modifying its behavior during the ...


3

There are several ways to do this. nohup 2>&1 application &. This will send all output to a file called nohup.out. It will also capture SIGHUPs. So you can close the shell and it will keep running. If you wish tyo see what is happening then you can follow the output with tail -f nohop.out. The tee command will do the same without preventing ...


3

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


3

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


3

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


3

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


3

my-program > >(pv -trabcN stdout > stdout) 2> >(pv -trabcN stderr > stderr) Would give you a progress like: stderr: 123MiB 0:00:03 [42.6MiB/s] [41.1MiB/s] stdout: 138MiB 0:00:03 [54.2MiB/s] [46.2MiB/s] (current (-r) and average (-a) speed. -a is relatively recent, you can omit it if your version of pv doesn't have it).



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