i'm connecting from a pc running Absolute Telnet 3.8 via a null modem cable to a linux box running Fedora Core 3. On the linux box, inittab has the line "5:2345:respawn:/sbin/agetty -L ttyS0 115200 xterm".
ABSTelnet is also set to xterm with UTF-8. And ... any use of "vi or less or man" causes the screen to be messed up. for instance "man" will show a few lines in the middle of the terminal window,leave the cursor above what it printed, cursor keys are ineffective, only thing to do is quit out and reset the terminal. ive tried all the available terminal types, all with the same result. any ideas ?? thanks.

[size=1][ March 15, 2005, 01:06 PM: Message edited by: Brian T. Pence ][/size]

David,

It sounds like it might be a flow control issue. To check this theory, telnet to the host and create a large file (several thousand lines) that contains some kind of repeating pattern... Like this...

A
BB
CCC
DDDD
EEEEE
FFFFFF
GGGGGGG
HHHHHHHH
IIIIIIIII
JJJJJJJJJJ
KKKKKKKKKKK
LLLLLLLLLLLL
MMMMMMMMMMMMM
NNNNNNNNNNNNNN
OOOOOOOOOOOOOOO
PPPPPPPPPPPPPPPP
QQQQQQQQQQQQQQQQQ
RRRRRRRRRRRRRRRRRR
SSSSSSSSSSSSSSSSSSS
TTTTTTTTTTTTTTTTTTTT
UUUUUUUUUUUUUUUUUUUUU
VVVVVVVVVVVVVVVVVVVVVV
WWWWWWWWWWWWWWWWWWWWWWW
XXXXXXXXXXXXXXXXXXXXXXXX
YYYYYYYYYYYYYYYYYYYYYYYYY
ZZZZZZZZZZZZZZZZZZZZZZZZZZ
A
BB
CCC
DDDD

and on and on..... (sorry, the pattern above only ligns up proprly with a fixed-width font. It may not look right in your web browser)

Now, connect to the host via the serial line and 'cat' the file. If there is a flow control issue, it should be very noticeable when you page back up through the scrollback. The pattern will appear broken and misaligned in multiple places because the flow control problem will cause data to be lost.

If this is the issue, you'll likely have to enable hardware flow control. To do this, you'll have to add the '-h' flag to agetty and also configure AbsoluteTelnet for hardware flow control (Options->Properties->Connection->COM->Configure Port)

Let me know if this helps

Brian

Hi Brian

well i did that and i did get problems(after some thousands of characters) which were solved by enabing hardware flow control. However it didnt cure the original problem. Some extra info about using man, the up arrow will cause "ESC0A" to be printed and the text to be pushed down a line, the down arrow causes a line of text to be printed which is immediately erased by the CR, no scrolling

dave

A couple of questions....

1. What is the value of the TERM environment variable after you login?

2. What is the setting of Absolute's terminal type?

3. Can you run the stty -a command at the unix prompt and give me a screen snapshot of the output or copy/paste the output here??

4. What is the setting in Absolute for 'Absolute Sends 7bit/8bit control sequences' on the Options->Properties->VTOptions page?

Brian

OK

1: TERM=xterm
2: Absolutes terminal type == xterm
3:
[dave@EPIA ~]$ stty -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\\; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl echoke
[dave@EPIA ~]$
4: Absolute sends 7 bit control sequences

dave

The problem now is that your host doesn't know the size of your terminal (see the rows and columns settings from the stty output). Without knowing the screen dimensions, full-screen apps (man, vi, pine, etc) will never know how to draw themselves, and sometimes don't bother trying. Try the following at the command line:

eval `resize`

(note the back-ticks)

Now check your 'stty -a' output to see if the rows/columns match what are displayed in the AbsoluteTelnet status bar (bottom left). If the rows and columns now match between your host and the terminal, then your man commands will now work. You may want to add the above command to your login script.

If that doesn't work, you can specify the rows and columns explicitly with the following command:

stty rows [number of rows] columns [number of columns]

where [number of rows] and [number of columns] can be taken from the screen dimensions displayed in the AbsoluteTelnet status bar.

Now, if you get that all working, it's worth mentioning that if you change the window dimensions in AbsoluteTelnet after login, you'll have to reset the window dimensions on the host by either re-issuing the 'resize' command or the 'stty' command.

Both telnet connections and ssh connections contain mechanisms to communicate the terminal size to the host on the fly. These mechanisms prevent the type of problem you're having. Direct serial comm connections are not able to do this and usually set the terminal size once at login time (using the commands mentioned above)

To prevent the terminal and host from getting out of sync, you may optionally want to enable the 'fixed size' option in Options->Properties->VT Options. With this option enabled, changes to the size of the AbsoluteTelnet window will scale the font but not change the screen dimensions. For example, an 80x24 screen will remain 80x24 and the font will change sizes to accomodate changes to the terminal window size.

This is probably more information than you expected. Let me know if any of it helps.

Brian

fantastic , that solved the problem.

thanks

dave

Glad to hear it!!!

For anyone else who might be reading, the 'eval `resize`' command queries the terminal to find out the actual terminal size.

The stty command explicitly sets the rows and columns on the host to specific values. (hopefully ones that match your terminal)

Either command could be added to your login scripts to set the terminal size at login time.

Above all, the rows and columns displayed in the stty -a output must match the rows and columns in the terminal (as displayed in the status bar) or most full screen apps will have difficulty drawing properly.

And another interesting note... Certain apps will still work, even when the rows and columns are not set. 'Pine' for example still displays properly when rows and columns are zero. Pine must have an alternate method of determining the screen dimensions when none are provided by the system.

Brian

[size=1][ March 16, 2005, 09:43 PM: Message edited by: Brian T. Pence ][/size]