Bug 76846 - Bad: vt100 emulation does not display MANpages correctly
Summary: Bad: vt100 emulation does not display MANpages correctly
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: termcap
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Petr Raszyk
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-28 03:14 UTC by Alfred Morgan-Jones
Modified: 2015-01-08 00:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-06 09:01:08 UTC

Attachments (Terms of Use)
Evidence of bug (50.50 KB, text/plain)
2002-10-29 00:15 UTC, Alfred Morgan-Jones
no flags Details

Description Alfred Morgan-Jones 2002-10-28 03:14:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
Using VT100/VT200 terminal connection over telnet, the man pages are mangled by 
RedHat Linux 8 distribution. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to RedHat8.0 server using any VT100 terminal emulator from a remote 
2. type : man useradd  (or similar)
3. Result fails to format correctly.

Actual Results:  Man pages mangled as per attachment 

Expected Results:  Output in correct format as per RedHat7.x

Additional info:

Comment 1 Alfred Morgan-Jones 2002-10-29 00:15:32 UTC
Created attachment 82484 [details]
Evidence of bug

Comment 2 Andrew Heybey 2002-10-30 13:35:01 UTC
I came looking for a man page bug and found this which I think is the same as
what I am seeing.  I think it is not a termcap problem, but a roff/troff/grotty
problem.  I see a similar problem when ssh'ing into a box from a gnome-terminal
(version 1.4.2 running on FreeBSD). (TERM=xterm in my case).

The problem that I see is illustrated by the following dump of the output of
"man man" on Redhat 7.3 vs. 8.0.  On 8.0, the dashes have been replaced by
characters with the high bit set.  (Note that I set GROFF_NO_SGR on the 8.0 box
to avoid other extraneous differences.)

On 7.3:

bash$ od -c man73.1.out

0000100   )  \n  \n  \n  \n   N  \b   N   A  \b   A   M  \b   M   E  \b
0000120   E  \n                               m   a   n       -       f
0000140   o   r   m   a   t       a   n   d       d   i   s   p   l   a

On 8.0:

bash$ od -c man80-nosgr.out
0000120  \n  \n   N  \b   N   A  \b   A   M  \b   M   E  \b   E  \n    
0000140                           m   a   n     342 210 222       f   o
0000160   r   m   a   t       a   n   d       d   i   s   p   l   a   y

There are three characters with the high bit set produced rather than a dash. 
This confuses my terminal.  Similar 3-character sequences are produced for a
hyphen to break a word (0342 0200 0220) and "`" (0342 0200 0230) and "'" (0342
0200 0231).

Don't know where the bug is (in groff/grotty or in my version of gnome-terminal)
but I worked around the problem by writing a filter to strip out the above
sequences and putting it in my MANPAGER pipeline.

Comment 3 Andrew Heybey 2002-10-30 14:05:21 UTC
I believe this bug is really a duplicate of 75089.

Comment 4 Thomas E. Dickey 2003-02-25 15:54:45 UTC
Actually, no reasonably accurate vt100 emulator would work with UTF-8.

Comment 5 Petr Raszyk 2005-09-06 08:59:37 UTC
vt100 terminal emulator emulates very old physical existing hard-ware
(15 - 20 years ago). This hardware/terminal-emulator understands only
'one-byte-characters' (ASCII characters).
You use 'very modern font' LANG=en_NZ.UTF-8. A UTF-8 font
supports 'multi-byte-characters'. 
If there is a vt100 terminal-emulator supporting UTF-8 fonts, this is
not vt100 emulator.

I assume, you are using a vt100-emulator in Microsoft Windows OS. You can
download a better emulator (Windows/Linux/Unix) at


Petr Raszyk

Comment 6 Thomas E. Dickey 2005-09-06 09:26:16 UTC
close, but not a very accurate reply.  Windows
console emulator supports the fonts.  Locale has
no direct relationship to the font (you actually
mean encoding).  The user's local is the issue. 
He can make this work by setting his locale to
POSIX.  A better choice for TERM would be
ms-vt100-color or ms-vt100+ (not vt100 or vt220).
See the comments in


The console emulator is capable of displaying
Unicode values, but Redhat doesn't have any software
capable of rendering it on that emulator.

Comment 7 Thomas E. Dickey 2005-09-06 09:45:36 UTC
See also http://www.columbia.edu/kermit/telnet80.html

Comment 8 Petr Raszyk 2005-09-07 09:43:52 UTC
We haven't spoken about MS Windows console. We are speaking 
about an executable, for instance PuTTY/pterm terminal-emulator 
(Windows/Unix/Linux). A graphical executable (MS Windows) is 
something different from the 'MS console'.
A second mistake: a shell-environment-variable is 'readable'
for any programs (in Unix/Linux/even MS Windows side).


void my_primitiv_function_doing_nothing (void)
{ char * char_poin_l;

 char_poin_l = (char *)getenv("MY_SHELL_VARIABLE");
 if (char_poin_l == (void *)0)
    { /* We do not return anything, we ignore this case */

If you look at any terminal-emulator-source, you will be 
wondering, what all happens. You will see that the 
'emulator'  'has/and must have' a knowledge about 'displaying font'.

To see, what all is possible, look at www.c-frame.com/downpage25.
Respectively, www.c-frame.com/changes/pterm.zip

Petr Raszyk

Comment 9 Thomas E. Dickey 2005-09-07 11:53:10 UTC
I looked at it.  sorry - I don't see a need to respond to
you any more. bye.

Comment 10 Petr Raszyk 2005-09-07 13:00:07 UTC
It is nice everything is clear now.

Note You need to log in before you can comment on or make changes to this bug.