finishing output translating stream
Shiro Kawai
(25 May 2005 00:05 UTC)
|
Re: finishing output translating stream
Michael Sperber
(06 Jun 2005 15:15 UTC)
|
Re: finishing output translating stream
Shiro Kawai
(07 Jun 2005 10:41 UTC)
|
Re: finishing output translating stream
bear
(07 Jun 2005 16:12 UTC)
|
Re: finishing output translating stream
Michael Sperber
(08 Jun 2005 07:19 UTC)
|
Re: finishing output translating stream
Shiro Kawai
(08 Jun 2005 07:37 UTC)
|
Re: finishing output translating stream
Michael Sperber
(08 Jun 2005 07:52 UTC)
|
Re: finishing output translating stream
Shiro Kawai
(08 Jun 2005 09:08 UTC)
|
Re: finishing output translating stream
Shiro Kawai
(08 Jun 2005 09:10 UTC)
|
Re: finishing output translating stream bear (08 Jun 2005 18:10 UTC)
|
Re: finishing output translating stream
bear
(09 Jun 2005 02:16 UTC)
|
Re: finishing output translating stream
Michael Sperber
(09 Jun 2005 05:51 UTC)
|
Re: finishing output translating stream
Shiro Kawai
(21 Jun 2005 00:00 UTC)
|
Re: finishing output translating stream
Michael Sperber
(22 Jun 2005 07:56 UTC)
|
On Tue, 7 Jun 2005, Shiro Kawai wrote: >If the translate-proc doesn't know about flush-output-stream, >and a log message happen to end with a non-ascii character, >it won't write out the closing escape sequence ESC '(' 'B' >at the end of log message, for it doesn't know if more non-ascii >character is coming or not. If the application crashes then, >the log file remains in the non-ascii state. Subsequent run >of the applicaion starts adding messages, assuming the file begins >with ascii state---resulting that the first ascii portion of >the new message becomes illegible. This argues that the translate-proc should "wrap" the output stream, so that it always knows about flush messages. It does what it must do, then passes the "flush" message on to the primitive output stream. Right? Bear