0

Sometimes I'll attempt a (2>&1) redirection and some/all of the resulting output appears to be silenced.

e.g.

wget -O- http://localhost/test.txt 2>&1

I would expect to see a merge of contents of test.txt and the output of the transfer, but instead results in only the output to stderr and not the output to stdout:

--2013-03-18 14:53:41--  http://localhost/test.txt
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9 [text/plain]
Saving to: `STDOUT'

 0% [                                       ] 0           --.-K/s              1100%     
    [======================================>] 9           --.-K/s   in 0s      

2013-03-18 14:53:41 (2.09 MB/s) - written to stdout [9/9]

Shouldn't stdout have written it to the screen?

And yet:

wget -O- http://localhost/test.txt 2>&1 > test.stdout

results in the file being written to test.stdout as expected.

Similarly I have seen this behaviour with expect scripts (send_user) and multiple grep pipes. e.g.

/myexpectscript | grep 'blah'

works and filters all lines but those containing 'blah', but

/myexpectscript | grep 'foo' | grep 'bar'

results in blank output.

How I discovered this was when I was wanting to use tee to duplicate output. e.g.

wget -O- http://localhost/test.txt 2>&1 | tee

results in no output at all, whereas:

wget -O- http://localhost/test.txt | tee

results in:

--2013-03-18 15:16:42--  http://localhost/ddns/checkip.php
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9 [text/plain]
Saving to: `STDOUT'

127.0.0.1100%[======================================>] 9           --.-K/s   in 0s      

2013-03-18 15:16:42 (2.30 MB/s) - written to stdout [9/9]

(Note line 8 lists the contents of test.txt "127.0.0.1")

Under what circumstances is redirected output blocked? Why does a supposed output to stdout by wget only work when redirected to a file or command?

2 Answers2

0

Here wget -O- http://localhost/test.txt 2>&1 does write the downloaded content to stdout.

grep 'foo' | grep 'bar' obviously results in no output if there are no lines containing both "foo" and "bar".

Hauke Laging
  • 5,285
  • 2
  • 24
  • 40
0

Since upgrading a couple of times, I find now that the behaviour is now as expected.

$ wget -O- http://localhost/test.txt 2>&1
--2015-10-06 14:39:58--  http://localhost/test.txt
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10 [text/plain]
Saving to: 'STDOUT’

-                             0%[                                             ]       0  --.-KB/s             It works!
-                           100%[============================================>]      10  --.-KB/s   in 0s     

2015-10-06 14:39:58 (918 KB/s) - written to stdout [10/10]

As you can see, at the end of the first line of progress "It works!" (the contents of the text file) is correctly merged with the output.

In the face of any other reasonable explanation, I can only conclude that this must have been either a bash or terminal bug of a cosmetic nature.