Sorry for the late response, I have been busy on other things...


In article <[log in to unmask]>, "Wirt Atmar"
<[log in to unmask]> wrote:

> In a message dated 5/27/02 7:59:01 AM Mountain Daylight Time,
> [log in to unmask] writes:
>
>> In article <[log in to unmask]>, "Wirt Atmar"
>>  <[log in to unmask]> wrote:
>>
>>  > ADVANCED TELNET ON HP-UX
>>  > ========================
>>  >
>>  > This will intrinsically be a long email, but the bottom line is:
>>  >
>>  >      o A new version of QCTerm is available that will allow an
>>  >      easier
>>  > simulation of advanced telnet on HP-UX (but not Linux). The new
>>  > version is Version 0.96f (May 25, 2002). To download the new
>>  > version, go to:
>>  >
>>  >           http://aics-research.com/qcterm
>>  >
>>  > ..download the new version and unzip it to the C:\ root as it is
>>  > primed to do.
>>  >
>>  > Steve Cooper wrote me yesterday and suggested that I try "stty
>>  > echonl" (echo linefeeds) when in host-suppressed echo ("stty -echo")
>>  > in order to even out the random LFs that I'd been seeing. Lo and
>>  > behold that worked, even though I'd tried it before. A little later
>>  > in the day I found out why it worked when Steve suggested it and it
>>  > didn't when I tried it. HP-UX responds to the command but Linux
>>  > doesn't, and I just happened to be on HP-UX at the time I was
>>  > talking with Steve.
>>  >
>>  >
>>  Well, Linux actually does respond to it. There's another reason why
>>  you don't see it. With (RedHat, SuSE, and others) Linux you're
>>  probably speaking to a bash shell, with HP-UX to a POSIX (mostly korn)
>>  shell. The bash shell has usually per default line editing enabled
>>  using the gnu readline library, korn doesn't. If you start up a new
>>  shell under Linux with like "sh -noediting", you'll get more or less
>>  the same behaviour as under HP-UX. The same is true while talking to
>>  "cat" for example. In fact, this is a nice way of seeing the
>>  difference between what gets echoed while talking to a shell, and when
>>  talking to cat.
>>
>>  The readline library enables line editing (correcting your mistakes
>>  while you type), and as such requires noncanonical mode because it
>>  (the shell/readline) has to interpret each character to see if it's an
>>  editing character.
>>
>>  In short, this doesn't work with your local-echo telnet, as each
>>  character needs to be delivered to the application (in this case the
>>  bash shell) as it is typed. The same holds for other noncanonical
>>  requiring programs, like man (well, actually "more" or "less" or
>>  whatever pager program is used by "man"), vi, etc.
>>
>>  You can *only* use "advanced" telnet with applications that only
>>  read/respond to a "line" of text, i.o.w, using canonical mode.
>
> Let me say at the outset that I very much appreciate you taking the time
> to write all that you did, but I don't think that your explanation is
> the source of the problem.
>


You're welcome, as much as I very much appreciate your efforts to supply
the HP terminal bound folks with a good emulator.

In short, I was trying to explain the difference in response you saw
between Linux and HP-UX, I was not trying to solve your problem as I have
too little knowledge of that.
As far as I understand it, what I wrote still holds.

In other words, if you want to have the same response in Linux, as you
have in HP-UX, it should suffice to do "exec sh -noediting", or better still
"set +o vi" or "set +o emacs" depending which editing mode is selected, to
get into canonical mode immediately after logon. This will result in the same
observed behaviour in Linux and HP-UX.

The sequence for Linux then becomes:

login
set +o vi
tset
<set advanced telnet mode>
stty -echo echonl

and you're on your way. You might get away with switching the last to
actions, to prevent the double echoing of the stty command. The tset
command was neccesary on my box to set the tabs stop at the correct position,
even if it does have the correct "hp" TERM setting. YMMV.

Tried it with your latest version of QCTerm, works on my systems. I have
noticed however that after switching to noncanonical mode (for example
by using man) and back to canonical, seems to mess things up in such a
way that can only be corrected by starting QCTerm again. No amount of
stty or QCTerm fiddling helps.


<snip>

>
> The fundamental mistake is that in any form of client-server
> architecture, both sides must constantly and accurately know the status
> of the opposite machine. In the asymmetric architecture of a
> host-terminal client-server configuration, the client must be assumed to
> be the primary driver of the negotiated statuses of the two devices.
>


Ok, I see your point. If that's not the case, and it was designed to be
in "the" TELNET protocol, something is wrong.
TELNET LINEMODE looks like it should do more or less what you want.
Don't know if the telnet servers in the wild all support this mode,
the docs say that this is a compile-time option.

> In the case of both Linux and HP-UX, the client (QCTerm) is sending the
> telnet command DONT ECHO, which both Linux and HP-UX are both properly
> responding to with a WONT ECHO, but which both are promptly ignoring and
> continue to echo characters anyway.
>
> Issuing the "stty -echo" at the command line is just a cheesy workaround
> to a very fundamental problem in telnet negotiation.
>

Could be. Can't blame stty for that though, it just does what it's
told. By comparison, if you're connected through a serial terminal, and
you tell stty to change the baudrates, it will do just that, regardless.


<snip>

regards,

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *