Måndag den 1:a augusti 2016, klockan 14:44, skrev Franc Grootjen detta:
> While writing a small telnet server application I stumbled upon some
> (for me) unexplainable telnet behaviour. The culprit is the behaviour
> of telnet program receiving a linefeed character (ascii 10). As far as
> I understand (from RFC854) telnet should as unconfigured NVT handle a
> linefeed as:
>
> Moves the printer to the next print line, keeping the same horizontal
> position
>
> So, that explicitly means without performing a carriage return.
> Funny is that after switching the telnet local echo off, (by sending
> IAC, WILL, ECHO) the behaviour changes, and the linefeed character keeps
> the same horizontal position.
> (See the commented line in the example source)
> So my questions are:
> - is this behaviour incorrect?
> - why does the behaviour changes after switching off the local echo
When the TELNET client receives 'WILL ECHO' it executes the snippet
reproduced below. The clearing of ONLCR means that the local line
discipline no longer implements the transformation 'NL -> CR+NL'
on output to the local output channel. Thus you do not observe
the expected printing of text flush to the left margin.
My guess is that the observed behaviour and coding is common to all
clients with origin at least in the netkit code base, which includes
Inetutils as well as the client brought forward by present BSD systems.
It even prevails in the client of OpenIndiana.
A related question: Do you know of any implementation where true
line mode works as expected without any supplementary action on
the client side, such as activating editing after choosing line mode?
I have yet to find such a system, and I am struggling to understand
why our code does not succeed in doing that.
Best regards,
Mats Erik Andersson
/* telnet/sys_bsd.c
* TerminalNewMode()
*
* Remote side WILL ECHO
* Client later responds DO ECHO
*/
#ifndef USE_TERMIO
sb.sg_flags &= ~ECHO;
#else
tmp_tc.c_lflag &= ~ECHO;
tmp_tc.c_oflag &= ~ONLCR;
#endif
