NOS vs NET telnet
- To: John.Ackermann@dayton.NCR.COM, email@example.com,
- Subject: NOS vs NET telnet
- From: firstname.lastname@example.org (Milton D Miller)
- Date: Sat, 23 Feb 91 17:20:05 -0500
The problem you mention I have also observed, and tracked down.
(To make sure that it wasn't happening to me right now, I did
some filtering on the raw mail file :-)) The fix, however, is
not quite as simple :-)
Anyway, the problem stems from the way end of lines are handled
in nos (since about last January), and the ambiguities that result
when only one of two characters is seen. In current nos versions,
as soon as it sees the first character of a multicharacter end of
line sequence, it assumes it has found the sequence, replaces it
with a '\n', and discards the next character. However, the
problem is that sometimes the next character is not the second
character of the eol. What can easily occur on unix systems
is two CRs are generated for one LF, becase the application and
the tty driver both insert a CR before the LF. The finger on
our system, for example, does not strip the CR's from the incoming
messgae before writing it to the tty driver, but the tty driver
does what it is told: whenever it sees a LF output CRLF. It doesn't
rember that the previous character was a CR anyway, nor should it.
Nos ses the first CR, discards the second, and then the pc somehow
manages to turn LF any_char into newline space.
The fix is to fix the socket code to actually check the second
character of the EOL sequence. That may inccur an extra wait,
but that should not be a problem in the general case. The hard
part is putting the extra character back in to the input stream
without looseing the second character (anyone up for usungetc()?).
An alternative check is to put the code of rrecvchr in recvchr,
and just peek at the next character. If it uses PULLCHAR,
it must call pushdown before "fixing" the data, because the
mbuf could have been freed by the pullup.
The relevent code is in sockutil.c if anyone is interested,
in recvchr() and rrcvchr().
PS: I have looked at the mailbox corruption problem a little here
today, and have narrowed it down to the mailbox code somewhere
between the temporary file and the screen output. However it is
hard to look at the code here, where there is no correctly
functioning curses on the PC (I can't change the config.sys as
it is in a public lab, and boots from the hard disk by itself.)
The error also occurs on input from the mailbox to the smtp
system. Also, I don't have a complier to check any code fixes.