On Wed, Jan 12, 2011 at 10:09 PM, Mike Miller <mbmiller+l at gmail.com<mbmiller%2Bl at gmail.com> > wrote: > On Wed, 12 Jan 2011, Robert Nesius wrote: > > > On Wed, Jan 12, 2011 at 3:40 PM, Mike Miller <mbmiller+l at gmail.com<mbmiller%2Bl at gmail.com>> > wrote: > > > >> > >> Regarding the system for keeping separate .out and .err files: I find > >> that the order of appearance on the terminal changes if the stderr and > >> stdout are produced at almost the same time: > >> > >> $ ( echo "stdout1" ; echo "stderr1" 1>&2 ; echo stdout2 ) > >> stdout1 > >> stderr1 > >> stdout2 > >> > >> So stderr was second, but here it is first: > >> > >> > >> $ ( ( ( echo "stdout1" ; echo "stderr1" 1>&2 ; echo stdout2 ) | tee > foo.out > >> ) 2>&1 1>&3 ) 3>&2 | tee foo.err > >> stderr1 > >> stdout1 > >> stdout2 > >> > >> Adding a few milliseconds between makes it come out in order: > >> > >> $ ( ( ( echo "stdout1" ; sleep .01 ; echo "stderr1" 1>&2 ; sleep .01 ; > echo > >> stdout2 ) | tee foo.out ) 2>&1 1>&3 ) 3>&2 | tee foo.err > >> stdout1 > >> stderr1 > >> stdout2 > > > > When you have two separate buffered streams going to the same file, > > there are no guarantees the temporal order will be preserved. The bits > > hit the file when the buffers are flushed by the kernel. If you're > > debugging a program that sends errors to stderr and output to stdout, an > > error message may appear well after the output on stdout that it was > > meant to be associated with. > > > Could that file be /dev/tty? In other words, there is no way to preserve > the temporal order of the outputs from the program, right? I guess the > lesson is that if we want to preserve the order, we have to write programs > that write to only one stream, maybing having errors go to stdout. We > could use ANSI color or some other scheme to highlight the errors. > > Mike > > It's line-buffered output - doesn't matter if it's /tmp/foo or a tty... You can go to "unbufferred I/O" to help mitigate this (an approach with performance implications), or simply make sure the stuff you care about is in the same stream. Remapping streams to be the same also helps. Its just an issue to be aware of is all... . Most people bump into this eventually in unix/linux. Often it's noticeable when I/O sent to stderr in the midst of writes to stdout is all bunched up at the end of the output, which happens because stdout gets flushed while tthe process is being torn down and filehandles flushed and closed. This usually motivates one to ask "Why did all of my debug statements get bunched up at the end?" -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20110112/438efd4a/attachment.htm