Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-412504 ] fileevent readable translation mode auto
|
From: <no...@so...> - 2001-04-09 18:25:54
|
Bugs item #412504, was updated on 2001-03-30 07:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=412504&group_id=10894 Category: Channel Commands Group: 8.3.2 Status: Open Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: fileevent readable translation mode auto Initial Comment: When fileevent (in translation mode "auto") sees a CR, it apparently waits to see if the next character is a LF before it proclaims EOL. It is looking one character ahead. In this way it avoids proclaiming two EOL's for one CRLF sequence. Would it not be better for fileevent to look one character behind instead? In this mode, when it sees a CR, it could immediately proclaim EOL. Also, when it sees a LF, immediately proclaim EOL, *unless* the previous character was CR, in which case the LF could just be discarded. ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2001-04-09 11:25 Message: Logged In: YES user_id=75003 All new files mentioned below are part of the uploaded archive "fet-notes.tar.gz". When trying out the example I noted that for me "fileeventthing-sh" did _not_ generate lines having \r (CR) as line separator. See file "shout" (SHell OUT) for an example, looked not with an editor, but 'od -c' to get a unimpaired look into the file. Because of this I wrote "numbergen", a tcl script doing the same. Its output is "shut.ng" and does contain the correct line separators, i.e. CR (side note: My emacs went into Mac submode! when displaying the file). The script "fet" is "fileeventthing-tclsh" modified to use "numbergen" for the spawned command pipe. It was also modified to display the times the fileevent was fired before printing the received line. Now testing the interaction all lines came in 1-second intervals, including the line for number 10. After that line was a 21-second wait for EOF, as expected. See file "fet.out" for a log. So, I was unable to reproduce the error on my system: % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = i586 tcl_platform(os) = Linux tcl_platform(osVersion) = 2.2.17 tcl_platform(platform) = unix tcl_platform(user) = tcl % info tclversion 8.3 % info patchlevel 8.3.1 Griff, please use the new scripts to check this out on your system too. Note, "numbergen" does [fconfigure stdout -buffering line -translation cr] to get the right line-separators and to avoid explicit flushing. This could be a difference with the original application too. IOW the original application / echo script may buffer the last line longer than is intended. The C library often acts differently, especially with regard to buffering output, when it detects that it talks to a pipe and not a pty (= terminal like xterm). This could be another reason for the problem you experience. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2001-04-08 13:40 Message: Logged In: YES user_id=75003 Note, that we have such an state-machine, search for SAW_CR. It rather seems that there is some bad interaction of this machine with the event system. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2001-04-08 12:44 Message: Logged In: YES user_id=79902 IIRC from the discussion this request arose from, we should use a little (two-state) state machine to spot whether to gobble CR/LF (the state is a boolean saying whether the last character seen was a linefeed.) None of this is needed when in any other line-translation mode than auto. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=110894&aid=412504&group_id=10894 |