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: Always Steps to Reproduce: 1. Login to RedHat8.0 server using any VT100 terminal emulator from a remote client. 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:
Created attachment 82484 [details] Evidence of bug
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.
I believe this bug is really a duplicate of 75089.
Actually, no reasonably accurate vt100 emulator would work with UTF-8.
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 http://www.chiark.greenend.org.uk/~sgtatham/putty/ Petr Raszyk
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 ftp://invisible-island.net/ncurses/terminfo.src.gz The console emulator is capable of displaying Unicode values, but Redhat doesn't have any software capable of rendering it on that emulator.
See also http://www.columbia.edu/kermit/telnet80.html
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). C-language: 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 */ } return; } 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
I looked at it. sorry - I don't see a need to respond to you any more. bye.
It is nice everything is clear now.