Re: app via inetd and telnet, terminal handling weirdness

It sounds like your terminal settings. If you are accessing via telnet then you are probably using some sort of terminal emulator, depending on whose telnet package you are using. On UNIX you should set the TERM environment variable to the same terminal type that your remote package is emulating, and make sure that you export it. For example a basic emulation done by some primitive packages use the old DEC terminal vt52 as their emulation target, so on UNIX you would set:

export TERM=vt52
[download]

If using C shell (csh or tcsh) you will need:

setenv TERM vt52
[download]

If you set TERM in one of your start-up files (.profile, .kshrc, .bash_profile, .login depending on which shell version and whether the session is a login shell or not) then you have to beware that you might require a different type when not using telnet (xterm, for example).

Display issues are often a mis-match of TERM and the emulator, or sometimes a really bad emulation. The fact that you do not have a problem when not using telnet only means that in that case your TERM setting is correct.

Comment on Re: app via inetd and telnet, terminal handling weirdness Select or Download Code

Replies are listed 'Best First'.
Re^2: app via inetd and telnet, terminal handling weirdness by kc2rgw (Initiate) on Jan 31, 2010 at 19:12 UTC
I'll play with a few more TERM types. VT100 oddly enough results in a blank screen, where 'dumb' got it going again. This is not only telnet, but will be a telnet session gatewayed by a packet radio session...about as dumb an interface as is possible. Thanks for the reply	[reply]
Re^2: app via inetd and telnet, terminal handling weirdness by kc2rgw (Initiate) on Jan 31, 2010 at 20:17 UTC
So with fresh eyes after some sleep. I think what is happening is, in telnet or within the 'node' application wrapper as an alternate way to run it, I think the /n is being stripped or not sent upon <enter key> of the input, so a second <enter> is registering the input finally still no luck with various TERM types though Is there a way to push a /n back through the interface? Sort of pre-load <STDIN> with a /n ?	[reply]