thanks everyone - I wish the man page were as useful. So if I understand correctly, a sequence of redirects </em>for a given command</em> just gets processed one after another overwriting previous redirects, and this all gets resolved before any i/o takes place ... (?)
I guess that explains why echo foo > bar1 > bar2 > bar3 > bar4 only writes to bar4. Also why the pipe-to-cat approach works ... the second redirection applies to the second command (cat) and doesn't overwrite the stdout redirection in the first (echo) ... (?) echo foo 1>&2 | cat > /dev/null similar if a subshell: ( echo foo 1>&2 ) > /dev/null ... the ">" redirect is resolved only after subshell runs ... (?) tx. Judah Michael Henry <[EMAIL PROTECTED]> wrote: > So for your test case: > > echo foo 1>&2 > /dev/null > > It starts like this: > > 0 --> IN (from terminal) > 1 --> OUT (to terminal) > 2 --> ERR (to terminal) OK > Then the `1>&2` switches the handle map: > > 0 --> IN (from terminal) > 1 --> ERR (to terminal) > 2 --> ERR (to terminal) Yup. > Then the `> /dev/null` redirection changes handle 1 again to point > to `/dev/null`: > > 0 --> IN (from terminal) > 1 --> /dev/null > 2 --> ERR (to terminal) > > which is why you get no output, because the echo command always > writes to handle 1. so the problem seems to be that the "> /dev/null" redirection is applied to the same process ... > But pipe redirections occur first, so > in this example: > > echo foo 1>&2 | cat > /dev/null > > the table for the `echo` command starts like this: > > 0 --> IN (from terminal) > 1 --> pipe to cat > 2 --> ERR (to terminal) > > Then the `1>&2` redirection takes place and you get: > > 0 --> IN (from terminal) > 1 --> pipe to cat > 2 --> ERR (to terminal) After reading through this, the man page (less than transparent, IMHO), and some web sites... let's see if I understand this now: "echo foo ..." 0 --> IN (from term) 1 --> OUT (to term) (echo output) 2 --> ERR (to term) "1>&2 ..." 0 --> IN (from term) 1 --> ERR (to term) (output of echo command) 2 --> ERR (to term) " | " 0 (IN) ---> IN (from term) 1 (ERR) went to term, so nothing passed 2 (ERR) went to term, ditto "cat" 0 (IN), took the "1" from previous step, i.e. null because it went to the term. 1 --> OUT (to term) 2 --> ERR (to term) "> /dev/null" 0 (IN) no change 1 --> sent to /dev/null 2 --> no change (goes to term) Kind of makes sense. I guess the critical thing is that all the redirects for a given process get processed one after another and can overwrite previous redirects. > Sorry I ran out of time - I'm late for church. Hopefully this > helps (and isn't full of typos), > Michael Henry
