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

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)


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


9

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


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

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


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

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


5

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


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

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


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

{ 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

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


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

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


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

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

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

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


2

V=`expr "$var" / "$var2" 2>/dev/null` but if division fails, result is empty.


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


2

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


2

output="$(./compass 2>&1 1>/dev/null)" if [ -n "$output" ]; then echo "$output" | mail ... fi


2

There is standard output (1), error output (2), and input (0). These are the standard file descriptors: tweedleburg:~ $ cat & [1] 13089 [1]+ Stopped cat tweedleburg:~ $ cd /proc/$! tweedleburg:/proc/13089 $ cd fd tweedleburg:/proc/13089/fd $ ls 0 1 2 Now the programmer can open files and every file opening delivers a file ...


2

As also ewhac pointed out, the error messages differ because the latter command line contains forward slashes (/), which causes your shell to interpret it as a file path. Both errors originate from your shell, which in this case is bash (which is evident from the second error message). More specifically, the first error originates from the ...


2

The / character is a pathname separator. The shell therefore assumes you're specifying a relative path to a command named unix.stackexchange.com under a directory named http:. The shell fails to find the directory or the file, and says so. You would get the same error message if you attempted to run a command named (for example): ...



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