Email list hosting service & mailing list manager

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)

Re: finishing output translating stream bear 08 Jun 2005 18:10 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