There are a number of wrong presumptions in your post about how some Unix-facilities work. I will try to address them one by one. Bear with me, sometimes the relation of explanation and problem will not immediately become clear. It will (should) make sense in the end.

You have to picture a Unix process like a garden hose. You put something in on top and it comes out at the bottom. If you connect two such processes with a pipeline symbol you stick two of these garden hoses together, so that the outcome of one goes directly into the other.

Now the picture of the garden hose is simple, but yet a bit misleading: first off, because processes change the data stream they are working on: you put lots of blue water in on top and get a small amount of red water out on bottom (or vice versa). But the more important shortcoming of the picture is that the garden hose is Y-shaped: it has two outputs, STDOUT and STDERR (and even more outputs if you defined them, but these two are there per default).

Notice that there is a strict difference between the outlet of a garden hose and the place it is directed at. You can catch what comes out of the hose by either this bucket or the other (or, see above, even the intake of another garden hose), but there is still a difference between the destination a hoses ending is pointed at and the destination itself.

Coming back to your script from this rather theoretical explanation: a command like "2>&1" means: "direct what comes out of stderr (one hose ending) to where the stdout (the other hose ending) is already pointing at". This does in no way imply that these two streams are now somehow "merged". They are not. They are just pointing to the same bucket, but are still two different hose endpieces. If you first redirect stderr to point to the same bucket (file or pipeline) as stdout and then redirect stdout to point to another bucket stderr will not be affected in any way - two different streams.

Now for another misconception directly related to your last point with the redirected "echo"s: in fact it is in no way guaranteed to get any particular succession if different streams are involved. If you write:

Code:

(echo a; echo b) | cat

you are guaranteed that "a" is displayed before "b". If you have "c" and then "d" coming out of stderr and you merge these two streams in one destination you are also guaranteed that "c" shows up before "d", but there is no such guarantee that "c" or "d" will show up in any particular position relatively to "a" or "b". it could be "a-b-c-d" or "c-d-a-b" or even "c-a-d-b" or "a-c-b-d" - all these variations would be valid ouputs for the following code:

Code:

(echo a; echo b; echo c >&2; echo d >&2) 2>&1 | cat

The reason is that stderr and stdout are radically different even if they look just like two of the same kind: one of them is buffered, the other one unbuffered. That means that repeated calls to output something are stored and then handled in one big rush versus processing each request as soon as it comes.


Another thing you seem to miss is a rather small issue: "sleep" can only handle integers. "sleep 0.5" might work on some system if this system has extended the standard but will definitely fail on most. If you want to "sleep for less than a second" i suggest you search this board for the "nodoff" utility Perderabo has programmed once.

I hope this helps.

bakunin