Bug 166702

Created attachment 118087 [details]
patch for kb problem for xterm and xterm-256color

A TERMCAP is very old description of terminal capability data base.
Today, 'each' program uses TERMINFO (/usr/share/terminfo/*/*  or $TERMINFO 
or ...). The reason is (for instance), that ncurses-5.4 must be specialy 
compiled to read TERMCAP if TERMINFO description does not exist and this is not 
the case in FEDORA CORE 4.
The capabilities of xterm are 'modern'. I mean, not all capabilities can be
described under TERMCAP. The resume is, that only very 'simple programs' 
(concerning output) can work with TERMCAP. I have added xterm and xterm-256color
into TERMCAP (including capability known by TERMINFO only). Please, send me a 
mail how your application under TERMCAP runs.

NOTE: A terminal-emulator (for instance xterm) does not read TERMCAP/TERMINFO.
      Only an application running in a terminal can (but does not need) to read 
      TERMCAP/TERMINFO.
      If you launch at command prompt (on any terminal - for instance xterm):

               stty erase b

      and if you try to write the text

               aaabbb

     you will see, that the character 'b' is your 'BACKSPACE' character now.
     The 'stty' command does not read TERMCAP or TERMINFO. 
     The 'stty' command does not modify TERMCAP or TERMINFO. If you tipe 

               stty -a

     You will see       erase=b;      instaed of      erase=^H;
     If you lanuch a terminal-oriented application (for instance 
     midnight-commander), this application will set the terminal to 
     'raw-mode'. Try to use the 'b' character in midnight-commander. 
     It works as character 'b' and not as 'BACKSPACE'. Before the 'mc' 
     terminates, it will set the original terminal settings.
     The character 'b' works as 'BACKSPACE' again.

Can you please put termcap-5.4 Rel.5 in fedora-updates so that current FC4 users
can take advantage of this? 
Thanks

termcap-5.4 Rel.6 added on Mon Sep  5 10:55:07 CEST 2005 (FEDORA CORE 4)

This fix causes the text editor I use (Jove) to incorrectly update the screen. 
I've written up this problem here:
  https://bugs.freedesktop.org/show_bug.cgi?id=4603

I fear that the xterm bug will be declared a feature  (I've verified that it
existed at least as far back as Red Hat Linux 7.0).  If so, I request that the
SR attribute be removed from the xterm entry in this new termcap since the
sequence does not work all the time.

I will attach a script that can be used to demonstrate the problem.

Created attachment 119286 [details]
shell script to demonstrate the bug -- read the comments

This tool (Jove) is not shipped with FEDORA CORE 4.
I will reproduce this issue. I did not found any *.rpm package.
I have tried to install 'jove-14.37.s.tar' on FEDORA CORE 4.
It does not work. There is output:
-----------------------------------------------------
cd . && autoconf
NONE:0: /usr/bin/m4: ERROR: EOF in string
autom4te: /usr/bin/m4 failed with exit status: 1
make: *** [configure] Error 1
-----------------------------------------------------

Do you have (or can you prepare) working Jove installation 
(but SOURCE installation  - i386, FEDORA CORE 4) ?
I will see how Jove reads termcap/terminfo.


I will change termcap/terminfo database (if xterm does not
support any property).

----------------------------------------------------
There is something important: i have 'added' new
termcap description for 'xterm'. I did not change/delete
any existing termcap/terminfo description for xterm.
I have changed xterm-256color termcap description only.
You can use 'original xterm description'. For instance:

export TERM=xterm-new       # <-- no change. <- Good for your issue.
export TERM=xterm-old       # <-- no change
export TERM=xterm-basic     # <-- no change


 

Re #7:
Thanks for trying to look at Jove.  There is no need for you to do so: you can
replicate the problem with the shell script that I attached.

(If you do wish to try Jove, you can fetch it from:
 ftp://ftp.cs.utoronto.ca/pub/hugh/jove-dev/jove4.16.0.67.tgz
In a parallel file, there is a PGP signature.  To build Jove:
 rpmbuild -ta jove4.16.0.67.tgz
But it took some time to reproduce and isolate the problem.  The script I
attached is a much better way to see what is going on.)

I use TERM=xterm on many computers.  No matter where the X server is, this
termcap entry is broken in the subtle way that I have described.

In fact, it is very bad form to change the xterm entry to match a new xterm. The
xterm is often on a different machine from the termcap database.  Think of ssh.
   So changes to the entry should only be made if ALL xterms get a new capability.

If I export TERM=xterm-whatever, then all my sshing to other systems without
such an entry will fail.  This is not a good solution.

The SR breakage is only observable in programs that (1) use termcap (I haven't
checked if terminfo (part of ncurses) is similarly broken), and (2) use the
xterm mouse support, and (3) are willing to attempt to use the SR capability.

Few programs use termcap.  Jove does so because it considerably reduces the
runtime size.  I have just checked terminfo (infocmp -C) -- it appears to have
the same problematic SR capability.

Few programs use xterm mouse support.  mc (Midnight Commander) is one, I think.

Neverthless, this is a real bug.  Since it is in years of fielded xterms (at
least back to RHL7.0), it is prudent for termcap not to advertise the broken
feature (SR).  Note that sr works, so the loss of SR is not important.

You *have* changed the xterm entry.  In termcap-5.4-4 on my non-updated FC4, the
xterm entry says tc=xterm-old, and this works.  On my updated FC4, the xterm
entry is all new, with the SR.

SR (termcap) == rin (terminfo) ==  scroll back #1 lines

Please:

1) Open a xterm

2) launch at command prompt
   ls -lisa

3) launch at command prompt
   tput rin 4

---------------------------------
'xterm' scrolls back #4 lines
'xterm' supports this capability.

NOTE: - tput reads terminfo.
      - I have created xterm-termcap-description via infocmp
        (from terminfo)

I will change termcap/terminfo !!!, but we must be sure (where (a
possible bug) is).

Re #9:
SR / rin works with FC4's xterm as long as the mouse tracking is not enabled. 
See ctlseqs.ms in the xterm distro for an explanation of mouse tracking
(optional, if you take my word for it).  Look at the script I attached in #6,
including the comments at the start.

This command enables mouse tracking:
        echo -n -e '\033[?1001h'
Issue that command and then try the commands: ls -lisa ; tput rin 4
The reverse scrolling will not happen.  So advertising that capability is wrong.

Created attachment 119545 [details]
tarball

xterm_1001h.tar

You are right. The sequence '\E[?1001h' can enable mouse tracking in
xterm (Does it have a termcap/terminfo name ?).
After this SR/rin does not work, ok. But '\E[?1001h' is not described in
termcap/terminfo and I can demonstrate that mouse-tracking and
SR/rin works fine. See attached exe/project. Compile, launch and
press the keys/mouse-buttons:

    F3
    mouse-button-down
    F2
    mouse-button-down


'Jove' reads something from termcap/terminfo and some sequences are compiled
into Jove-binary (?) It seams so. Then 'Jove' can avoid this
'bug': 
if TERM==xterm && SR == TRUE
   {ignore SR;}

But one thing is sure: using ncurses mouse-tracking and SR/rin 
works fine.
I should not remove 'working' SR/rin sequence from termcap/terminfo because an
aplication uses an undocumented sequence (compiled into
C-Code).


NOTE: there is a bug in xterm. If you submit the sequence '\E[?1001h'
      twice and if you press mouse-button-down, the xterm will hang.
      Compile and run attached binary file and press the keys:
      F1, F1, mouse-button-down.

Re #11:

About xterm_1001h.tar

- why didn't you just explore with the shell script I attached in #5?

- I've never heard of C-Frame.  Or anything on UNIX/Linux being refered to as an
exe.

- curs_mouse(3x) is new to me.  According to the man page, it is a ncurses
extension and it is not part of SVR4 or BSD curses.  Although designed for xterm
mouse tracking, it does not support all xterm mouse tracking.  It does not
support the kind of mouse tracking that I am encountering problems with.  It has
nothing much to do with termcap since it is built on terminfo.


About documentation of '\E[?1001h': cltseqs.ms

- xterm control sequences have always been described in an obscure document
called ctlseqs.ms in the X distibution (and nowhere else).

- .ms indicates that it is an nroff/troff document to be formatted with the ms
macro package.

- There is a derived PostScript file in Fedora Core 3 called
/usr/share/doc/xorg-x11-doc-6.8.2/xterm/ctlseqs.PS.gz.  This is part of
xorg-x11-doc-6.8.2-1.FC3.13.  It was also included in previous Fedora and Red
Hat releases.

-  As I understand it, xterm has been moved out of the xorg distribution, so
ctlseqs.ms has probably gone with it.  Unfortunately, ctlseqs no longer appears
in Fedora Core 4's /usr/share/doc.  I'd call this a bug.


Is there a bug in the newly released termcap?

- I have demonstrated a problem

- the problem is new behaviour: JOVE has done xterm tracking on dozens of
different UNIX/Linux releases since about 1990.  The first time I encounted this
problem was when I installed the recent FC4 termcap update.

- I actually think that the problem could be considered an xterm bug (and have
reported it as such).

- I think that the prudent "temporary" fix is to remove SR capability from
xterm's termcap entry.

- I actually think that SR should never be added for another reason.  xterm is a
well-defined terminal, with well defined control sequences.  This meaning
crosses system boundaries.  When using ssh, for example, the xterm on one
machine is responding to sequences specified in the other machine's xterm
termcap entry.  Updating xterm on one machine does not update it on another.  So
 capabilities not in ALL xterms should not be in the termcap xterm entry.  To
expose new capabilities, define a new termcap entry: xterm-whizbang.  The same
goes for terminfo, but Jove does not use it on Fedora and this bugzilla entry is
about termcap.

- BTW, a quick google suggests that this form of mouse tracking is also used by
vile and by splitvt.

You have a question:
- why didn't you just explore with the shell script I attached in #5?
  My answer: 
             It does not demonstrate anything.

- I've never heard of C-Frame.
  My answer:
             We have never spoken about C-Frame (121). This is not
             for a discussion  (this is not for you, C-Frame121 is a
             private tool).
             Again: we speak about a "possible bug" in termcap/terminfo
             description.
  
- I've never heard on UNIX/Linux being refered to as an exe.
  My answer:
            "exe" is a suffix only. Do not be afraid of this. This is 
             only a extension.



I will help you with your issue. But this is not possible. You are
speaking out of-topic.



It has no sense to go through your "next sentences".

I will close this "bug" as NOT A BUG.