George <greerga@CIRCLEMUD.ORG> writes:
> Right. Assuming the telnet-correct codes, the following would work:
>
> diff -u stk/comm.c nl/comm.c
> --- stk/comm.c Fri Jul 3 15:07:39 1998
> +++ nl/comm.c Sun Sep 27 22:59:12 1998
> @@ -1664,7 +1664,12 @@
> write_to_q(tmp, &t->input, 0);
>
> /* find the end of this line */
> +#if 0
> while (ISNEWL(*nl_pos))
> +#endif
> + if (ISNEWL(*nl_pos))
> + nl_pos++;
> + if (ISNEWL(*nl_pos))
> nl_pos++;
>
> /* see if there's another newline in the input buffer */
>
> That'd also work for \n\r but break on a simple \r or \n.
I don't think this will work -- what if there are two \n's in the
input stream, with no intervening \r? The client sends strictly in
Unix type file mode I believe -- never a \r. I could perhaps be
mistaken, though. So two blank lines get transmitted as "\n\n" which
causes the problem.
The right answer is to skip exactly one \n, and exactly one \r on one
side of the \n or the other (not both). I think, anyway. The mudFTP
client totally strips out \r's, so skipping twice won't work, since it
can hit two \n's.
What do most clients send? Do they conform? I assume they send \r or
\n but not both -- correct?
--
James Turner turnerjh@pattern.net UIN: 1102038
http://www.vuse.vanderbilt.edu/~turnerjh/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST