> notice that incrDay(), written after the others, is first. other
> oddity, later writes (this thing checks date functions for 200 years,
> *lots* of outout) seems to mix up the data when stderr and
> stdout are mixed:
This is NOT a bug! You are *guaranteed* to have this problem!
The ANSI Standard does NOT address this issue (deliberately) and leaves
it to the implimentor. In all compilers I know of, stderr is normally NOT
buffered, while stdout IS buffered. Intermixing them will give you just
this result. Anything to stderr will go *NOW*, while stdout will go when
a buffer full accumulates OR when you fflush(stdout).
Even if the were both unbuffered (or you setbuf'ed stdout), there is NO
guarantee that intermixed streams will come out in any particular order.
Other implimentation-specific factors *may* influence different streams
differently.
> no data is lost, but the buffered output was broken in half! normally,
> the \n should flush things, especially w/ respect to subsequent writes.
> could be bash is doing something funny, could be the libc's FILE is
> screwey, could be the fd is doing somethng funny.
BASH has NOTHING to do with what happens INSIDE the execution of another
application.....
> junk 2>71 | tee a;
^
&
>
> produced the same results (i.e., pipe to tee sees the same wierdness
> as redirect direct to a file on disk).
It *WILL*, for the same reason....
-----------------------------------------------------------
Brian A. Lantz http://www.lantz.com brian@lantz.com
REAL PORTION of Microsoft Windows code:
while (memory_available) {
eat_major_portion_of_memory (no_real_reason);
if (feel_like_it)
make_user_THINK (this_is_an_OS);
gates_bank_balance++;
}