Bug 122815

Summary: Keys "End" and "Pos1" aren't working in less
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: ncursesAssignee: Eido Inoue <havill>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 2CC: bugzilla.redhat.com, dbaron, dgunchev, dickey, fedora, gustavo, hdegoede, iml, johnny, jorton, kajtzu, marc.deslauriers, marcjw53, mattdm, mszpak, notting, oak, osvetlik, rodd, rstrode, umar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 5.4-13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-03 16:32:41 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 128822, 128823    
Bug Blocks: 123268, 136451    
Attachments:
Description Flags
patch fixing the problem
none
Patch fixing the original problem and the bug reported in comment 9
none
set TERM based on COLORTERM during profile startup
none
same as prev, except leave TERM alone if COLORTERM not set
none
new term.sh incorperating suggestion made in comment 60
none
patch fixing problem1 in comment 59 and all problems in comment 62
none
patch taking terminfo.src to the version given by Thomas Dickey in comment 67
none
patch fixing the problems mentioned in comment 68, this one should be applied on top of the previous one
none
patch fixing the problems mentioned in comment 68 updated to reflect the problems with this patch mentioned in comment 71, this one should be applied on top of the terminfo.src update
none
improved patch fixing the problems mentioned in comment 68 updated to reflect the problems with this patch mentioned in comment 71, this one should be applied on top of the terminfo.src update
none
tarball containing dirs with patches to either fix plain ncurses-5.4, or to take it to the latest ncurses-snapshot and terminfo.src and then fix it
none
slightly tweaked term.sh
none
ncurses-5.4-color_xterm.patch none

Description Robert Scheck 2004-05-08 10:45:50 EDT
Description of problem:
The keyboard keys "End" and "Pos1" aren't working in less for faster
viewing a file.

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

How reproducible:
Everytime

Steps to Reproduce:
1. Login for example over SSH
2. Use the default TERM=xterm or set it.
3. do a "less <larger file than one display size>"
4. Press "End" or "Pos1" at your keyboard
5. Get the non-working result
  
Actual results:
Default TERM="xterm" at bash is used, but TERM="linux" solves it. 
But they keys End" and "Pos1" have to work also work at xterm...

Expected results:
Keys "End" and "Pos1" should work over ssh using xterm, too ;-)
ncurses-5.3-4 (from Red Hat Linux 9) hasn't that problem, for 
example.
Comment 1 Robert Scheck 2004-05-08 16:15:04 EDT
It seems so, that the problem came up after ncurses-5.3-9.3 (RHEL 3).
Sorry, I don't have more packages between 5.3-9.3 and 5.4-4.1 to 
trigger out the problem exactly.
Comment 2 Joe Orton 2004-05-26 05:30:26 EDT
*** Bug 124039 has been marked as a duplicate of this bug. ***
Comment 3 Joe Orton 2004-05-26 07:36:14 EDT
This is a particularly annoying bug.  Affects mutt, nano, less...
Comment 4 Hans de Goede 2004-05-26 09:25:55 EDT
This problem is caused by the so called fix for bug 115448. I must say
that I'm shocked by the logic in this bug report:
* hey something broke colors in some apps
* hmm setting TERM to gnome-rh9 fixes this
* bla
* letts hardcode a link of TERM=xterm to TERM=gnome-rh9 in terminfo
me:
* GASP *

Hello, people do use other terminal emulators to. I believe atleast
konsole also is officially supported by Fedora, we also have the real
xterm and others. Besides that people who use a remote terminal
connection to a FC2 system might also appreciate a somewhat sane
default xterm terminfo entry.

This leads me to 2 possible terminfo fixes, first the preferred one
-add an xterm-redhat (like there still is in termcap, and
 like there used to be, which has always worked fine):
 *which links to xterm-xfree86 (which should also fix the vim problem)
 *which adds the RH/debian kbguidelines mappings for home and end
-make xterm point to xterm-xfree86

Or atleast fix home and end by adding a mapping for home and end to
the gnome terminfo entry which for some reason doesn't have any
entries for the home and end keys, and seems broken in general.

I'm going to write patches for both these fixes right now and will
attach those later today. BTW next time something like this breaks
please try to look bakc to what might have caused the breakage and
undo this, things like this are very delicate and the old solution is
very well tested.

* AAARGGGHHHH *

I just tested konsole and gnome-terminal and they don't send the
redhat/debian kb guideline sequences for home and end anymore but
instead send other ESC sequences. I now have 3 xterm clone temrinal
emulators:
-xterm
-gnome-terminal
-konsole

Which each send different esc-sequences for home and end, so fixing
terminfo is impossible since there is NO default/correct behaviour to
put in terminfo.

I've been working with RH to get this right since 6.2 and it used to
work fine, why o why have all the patches for this been blindly
dropped when upgrading to newer upstream versions without checking why
those patches where there in the first place?

I've decided to skip one (ONE!) beta cycle and everything in the
textmode/xterm keybindings world is messed up again.

Sorry but this really frustrates me.

In order to fix this we need to:
-decide what the correct esc-sequences for home and end under a
terminal claiming to be xterm are.
-decide to which terminfo entry xterm should point (preferably
xterm-xfree86.
-fix terminfo, gnome-terminal, konsole and xterm.

I'm going to assume that rh ones FC2 to be compatible with rh 6.2-fc1
(wenn using a remote terminal to/from these) and still wishes to
follow to debiankeyboard guidelines (for the esc sequences for home
and end, which was decided in the 6.2 days).

So I'll create a bunch of patches to put this all back to the way it
used to be and it used to work. I'll submit the gnome-terminal and
konsole patches under a new bug, pointing to this bug for the explanation.

For those wanting to know more on this just search on bugs submitted
by me, I've already explained this too many times.
Comment 5 Hans de Goede 2004-05-26 09:48:13 EDT
Created attachment 100583 [details]
patch fixing the problem

Replace the 5.4-color_xterm patch by this one and you will atleast have an
entry in the xterm terminfo for home and end, this entry currently contains the
esc-sequence as used in the past, meaning that it will only work in xterm.

I'll produce patches for gnoem-terminal and konsole to fix this. (sigh)

In the meantime to see what this patch does try: "tput khome; echo $?" before
and after this patch as you will see $? is 1 before this patch because
currently there is NO definition for khome (and kend) in terminfo's xtemr
entry.
Comment 6 Hans de Goede 2004-05-26 10:03:39 EDT
Well, gnome-terminal (vte) seems to determine the ESC-sequences for
home and end by reading them from ncurses, so fixing ncurses also
fixes gnome-terminal, hurray!
Comment 7 Joe Orton 2004-05-29 08:58:49 EDT
ncurses rebuilt with Hans's updated -color_xterm patch fixes all my
HOME/END problems in gnome-terminal using nano/mutt/less.  Thanks Hans!

Adrian, can this get built as an FC2 update please?
Comment 8 Robert Scheck 2004-05-29 10:50:58 EDT
Thank you very much, Hans, your patch solves my issue! :) 

Now, I only can add me to Joe's request...can we get an official 
update, Adrian?
Comment 9 Joe Orton 2004-05-30 05:59:13 EDT
Hmmm, I'm seeing issues using mutt in gnome-terminal: open a long
message, hit PgDown twice, and the display is corrupted with
characters left over from previous screen, Ctrl-L is needed to display
the page properly.  This seems to be a regression since the FC2
ncurses, it goes away if I revert.
Comment 10 Thomas E. Dickey 2004-05-30 06:12:59 EDT
That sounds like a problem reported elsewhere (one
of the bugs in gnome-terminal).
Comment 11 Thomas E. Dickey 2004-05-30 06:24:08 EDT
see for example
http://bugs.gentoo.org/show_bug.cgi?id=43970
(I tried a while ago to subscribe,
but that website is mildly broken).
Comment 12 Joe Orton 2004-05-30 06:30:08 EDT
OK, yes, I do see that sometimes with the vanilla ncurses-5.4-5
packages too, so I guess it's not a regression in Hans' patch.

Is this scrolling problem fixed in one of your patches for 5.4, do you
know, Thomas?
Comment 13 Thomas E. Dickey 2004-05-30 06:41:55 EDT
The real fix is to use the terminfo entry that I made for
gnome-terminal (which doesn't use features that it doesn't
implement correctly).
Comment 14 Thomas E. Dickey 2004-05-30 06:48:07 EDT
I noted in another place that the problem is that
gnome-terminal doesn't implement indn and rin
properly.  (That was on bug-ncurses, whose archive
doesn't seem to be reachable - my email says it was
on April 3, 2004).
Comment 15 Hans de Goede 2004-05-30 09:22:54 EDT
Hmm,

ncurses-5.4-5 as shipped with FC2 contains an xterm terminfo entry
which uses / is based on gnome-rh9. Thomas does that mean that the
gnome-rh9 terminfo entry is NOT the terminfo entry that you made?

Ifso where can I get your terminfo entry and what are the differences
compared to plain xterm-xfree86 ?
Comment 16 Hans de Goede 2004-05-30 09:41:46 EDT
As promised I've created a patch fixing the home and end keys in
konsole, see bug 124803

p.s.

I think we should wait for Thomas before applying my fix to ncurses,
if we can get a descent xterm terminfo entry which also works around
some gnome-terminal bugs that would be even better. My suggestion is
to use the xterm-xfree86 terminfo entry as a base but to leave out
options not supported properly by gnome-terminal.



Comment 17 Thomas E. Dickey 2004-05-30 10:53:59 EDT
That would be "gnome-rh90".  Ignoring the function keys, there
are several interesting differences (glancing over the list,
they're things that are either not implemented in gnome-terminal,
or which it does incorrectly).  Bear in mind that's from last
year - Fedora's gnome-terminal may have different problems.
For each line from infocmp, I could probably write a sentence
or two, but that takes time:

comparing gnome-rh90 to xterm-xfree86.
    comparing booleans.
        mc5i: F:T.
        npc: F:T.
    comparing numbers.
    comparing strings.
        blink: NULL, '\E[5m'.
        cbt: NULL, '\E[Z'.
        cnorm: '\E[?25h', '\E[?12l\E[?25h'.
        cvvis: NULL, '\E[?12;25h'.
        el1: NULL, '\E[1K'.
        enacs: '\E)0', '\E(B\E)0'.
        hpa: NULL, '\E[%i%p1%dG'.
        ich: NULL, '\E[%p1%d@'.
        indn: NULL, '\E[%p1%dS'.
        invis: NULL, '\E[8m'.
        is2: '\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>', '\E[!p\E[?3;
4l\E[4l\E>>
        mc0: NULL, '\E[i'.
        mc4: NULL, '\E[4i'.
        mc5: NULL, '\E[5i'.
        rin: NULL, '\E[%p1%dT'.
        rmcup: '\E[2J\E[?47l\E8', '\E[?1049l'.
        rmso: '\E[m', '\E[27m'.
        rmul: '\E[m', '\E[24m'.
        rs1: NULL, '\Ec'.
        rs2: '\E7\E[r\E8\E[m\E[?7h\E[?1;3;4;6l\E[4l\E>', '\E[!p\E[?3;
4l\E[4l\E>>
        sgr: '\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m%?%p9%t\016%
e\017%;', >
        sgr0: '\E[m', '\E[m\017'.
        smcup: '\E7\E[?47h', '\E[?1049h'.
        tbc: NULL, '\E[3g'.
        vpa: NULL, '\E[%i%p1%dd'.
Comment 18 Hans de Goede 2004-05-30 15:20:44 EDT
Hmm,

My main (only) expertise when it comes to terminfo are keymappings,
the other stuff I've never touched. So I could really use some help on
this :)

But I've always learned if something is worth doing it is worth doing
well. Thomas, are you willing to help me and / or do you know a quick fix?

My suggestion for a quick fix would be to use gnome-rh90 and fix the
keys, but what kind of influence would this have for people using the
real xterm (me), or using konsole (lots)?

BTW what about Joe's comment that the corruption also happens with the
vannilla ncurses-5.4-5, that suggests that using gnome-rh90 doesn't
completly fix this.
Comment 19 Thomas E. Dickey 2004-05-30 15:33:31 EDT
I'm not sure how to interpret Job's comment (it doesn't say what
terminfo entry he was actually using).
Comment 20 Thomas E. Dickey 2004-05-30 15:36:41 EDT
For the keys - Redhat has redefined most of xterm's function keys
so they don't match the terminfo.  Deleting most of their changes
to the XTerm app-defaults file would improve things.  It's sort of
strange that gnome-terminal can copy the keyboard layout I made for
xterm, but Redhat packager insists that users don't want it in xterm.
Comment 21 Hans de Goede 2004-06-01 04:41:48 EDT
About the scrolling problems Joe is seeing, I can't reproduce them
with vim or irssi (both are mentioned on the gentoo bug link), I'll
try with mutt next. I assume he is using TERM=xterm, with xterm
pointing to gnome-rh90 (which it does in the vanilla FC2 ncurses-5.4-5)

About the xterm function keys, this is an old patch of mine, which in
those days used to be correct (make shift F1-F10 send F11-F20) back
then gnome-terminal used todo this too. I've already submitted a patch
to fix this see bug 100695. But unfortunatly this patch has been refused.

Comment 22 Thomas E. Dickey 2004-06-01 09:15:59 EDT
yes - I noticed the 100695 report too late to respond (perhaps
there's a way to have Redhat's bugzilla tell me about these as
they're reported rather than require me to trawl for them).

The unmodified xterm translations use the control-key modifier
since 1996 when I added DECUDK support (DECUDK is documented to
use the shift-key).  My recollection is that this change came
before Redhat's customization that uses the shift-key for keys
F12-24 (or F10-F22).
Comment 23 Eido Inoue 2004-06-01 16:11:51 EDT
comment 7, comment 8: i've still testing the terminfo against the
common list of "usual suspects" (especially important are the
sshing/serial port terminals using the TERM=xterm case)

also need to talk to nalin re current behavior in gnome-terminal
Comment 24 Eido Inoue 2004-06-01 16:25:09 EDT
*** Bug 123987 has been marked as a duplicate of this bug. ***
Comment 25 Hans de Goede 2004-06-02 09:12:58 EDT
I've successfully reproduced the problem Joe mentions in comment 9, and 
I've also written a fix for it by using xf86-v43 as the base for
xterm-redhat (to which xterm then points) xf86-v43 doesn't use indn or
rin which indeed seems to be the problem.

This seems a correct way to fix things to me, since it basicly takes
the xterm terminfo entry back to the way it was with FC1
Comment 26 Hans de Goede 2004-06-02 09:14:32 EDT
Created attachment 100794 [details]
Patch fixing the original problem and the bug reported in comment 9
Comment 27 Eido Inoue 2004-06-04 16:44:56 EDT
This patch seems to hose line drawing with mutt through
gnome-terminal. I'll need to look at it more carefully to see if it's
salvagable, but in the meantime I can't take the patch as-is.
Comment 28 Hans de Goede 2004-06-04 16:52:39 EDT
Adrian,

Do you mean my first or second patch, and can you give my a quick step
by step on how to reproduce the problem?

Maybe I should write a patch which just adds the home and end keys to
the ncurses as currently shipped?
Comment 29 Thomas E. Dickey 2004-06-04 19:02:00 EDT
I have an impression (from the other reports) that the line-drawing
problem is a bug in slang.  Just for amusement, you might try
building mutt with ncursesw...
Comment 30 Karsten Hopp 2004-06-13 13:52:55 EDT
*** Bug 125881 has been marked as a duplicate of this bug. ***
Comment 31 Hans de Goede 2004-06-14 01:52:58 EDT
Yet another duplicate, so it seems this bug is really anoying people,
time to fix it.

I now my fix has problems, I assume those line-drawing problems with
mutt don't happen with the current release of ncurses. If that is the
case I can create a fix which just adds home and end to the current
terminfo xterm entry.

Also I would still like a step-by-step on how to reproduce these problems.
Comment 32 Need Real Name 2004-07-04 16:55:16 EDT
what's the status of fixing this annoying issue?
Comment 33 Eido Inoue 2004-07-06 17:41:40 EDT
The proposed fix is as follows:

#1. revert the xterm definition back to the stock terminfo.src

#2. Use new profile script to detect the two most popular color
terminals (konsole and gnome-terminal), and set the TERM to either
konsole or gnome appropriately, or to something else if COLORTERM is
set to something wild. If COLORTERM is unset, set the TERM to
something reasonable, like the latest xterm definition.
Comment 34 Eido Inoue 2004-07-06 17:44:58 EDT
Created attachment 101668 [details]
set TERM based on COLORTERM during profile startup

not sure why konsole sets COLORTERM but leaves it blank. "gnome" should
reference the latest gnome-terminal def. likewise for "konsole"... except the
konsole definition is only in later versions of ncurses; does not seem to be
present in RHEL3 (is present in FC). "xterm-new" should pull in the newest
xterm definition for xorg X-- and should be a relatively sane fallback when
sshing into a box.
Comment 35 Eido Inoue 2004-07-06 18:03:14 EDT
Created attachment 101670 [details]
same as prev, except leave TERM alone if COLORTERM not set

remove the setting of TERM for the case of remote logins as per Katz's
suggestion on fedora-devel
Comment 36 Robert Scheck 2004-07-06 19:12:39 EDT
Well Adrian, could you also do a offical rebuild for Fedora Core 2's 
update repository, if that solution is working fine (sorry, I didn't 
test it, yet)?! Would be nice - thanks :)
Comment 37 Eido Inoue 2004-07-06 19:16:38 EDT
comment 36: that's currently in progress (CLOSED RAWHIDE usually
implies pushing to the repositories, which is done automatically for
most FC* target collections a instance is built for)
Comment 38 Eido Inoue 2004-07-06 19:17:34 EDT
comment 36: i should add that the fix is two part; in addition to the
new ncurses, you'll need the new setup (when it's built)-- or place
the term.sh file in the patch section in /etc/profile.d
Comment 39 Hans de Goede 2004-07-07 02:39:08 EDT
There ara 1 big problem and two small problems with this fix:
-the big problem is that it doesn't fix home and end, the original
 problem was that the xterm terminfo entry used the gnome terminfo
 entry which doesn't have home and end defined, now the xterm terminfo  
 entry is ok, but the new term.sh makes $TERM be gnome for 
 gnome-terminal, and the gnome terminfo entry still doesn't contain
 the ESC-sequences for home and end, I can write a patch to fix this.
-the 1st small problem is that gnome-terminal in an attempt to get
 around problems with terminal versus terminfo mismatches, uses
 terminfo to decide which esc-sequences to use for certain keys,
 for example home and end. With the old ncurses, where xterm pointed 
 to gnome, gnome-terminal couldn't get any esc-sequences for home and
 end (since the gnome terminfo entry doesn't have these) and used its
 default esc-sequences. With the new terminfo (ands setup.sh) it uses
 the esc-sequences which are defined in the xterm terminfo entry.
 So here we have a situation where gnome-terminal behaves accordingly
 to the xterm terminfo entry but $TERM is set to gnome. Now is
 that logical or what?
-the 2nd small problem is that this fix is ugly as hell. As I've shown
 with my second patch it should be possible to create one simplified
 xterm terminfo entry which works for all terminals.

My suggestions are:
-tell me how the hell to reproduce the mutt line drawing problem and
 I'll look at it
-or ask me to write a fix for the gnome terminfo entry defining home
 and end (and some other keys while I'm add it)
 -and incorperate this fix and make xterm point to gnome
  like it does in the current shipped ncurses, which doesn't seem
  to cause any problems except for home/end
 -or incorperate this fix and use term.sh

So in order of (my) prefeference we've got:
-still go for the default xterm entry for all terminals and look at
 the mutt problem.
-fix the gnome terminfo entry and make xterm point to it 
-fix the gnome terminfo entry and use term.sh

An advantage of the last fix is that konsole uses its own terminfo
which gives possibilities to fix bug 124803
Comment 40 Hans de Goede 2004-07-07 02:40:45 EDT
p.s.

Since this isn't fixed it should be reopened but I haven't got the
rights todo that.

Also I read above that certain aspects of this bug we're discussed on
fedora-devel, please don't do that what is the purpose of a
bugtracking system if the decisions on how to fix the bug are made
elsewhere?
Comment 41 Robert Scheck 2004-07-07 02:42:55 EDT
Reopening, because the latest proposed solution doesn't really solve 
the original problem, thank you Hans.
Comment 42 Kaj J. Niemi 2004-07-15 08:01:45 EDT
Uh, setting TERM=gnome breaks just about every remote system I have
access to. Solaris, HP-UX, FreeBSD, etc. systems do not know anything
about it.
Comment 43 Hans de Goede 2004-07-15 10:00:02 EDT
Havill,

Kaj has a very good point, that leaves the following 2 options 2 fix this:
-go for the default xterm entry for all terminals and look at
 the mutt problem. (this requires being able to reproduce this
 problem)
-fix the gnome terminfo entry and make it the default xterm entry

I'm willing to write either fix. Just decide which one I should write.
Lett me also point out that FC3 is coming soon and it would be very
nice to have this fixed before FC3. Just make the call and I'll write
the fix.

Comment 44 Robert Scheck 2004-07-15 10:06:21 EDT
Marked as FC3 target bug. Well, again, the latest available update 
packages don't really solve the issue for me, awaiting response from 
Adrian Havill...
Comment 45 Thomas E. Dickey 2004-07-15 10:10:26 EDT
Kai would have a good point if gnome-terminal's functionality
corresponded to the terminals on those other systems.  Since
it does not (and I, too frequently get complaints about the
bugs in gnome-terminal), it would be a better solution if
gnome-terminal identified itself properly.  (If it's really
supposed to be a supported and standard terminal, it should
do that - as a minimum).
Comment 46 Hans de Goede 2004-07-15 10:23:31 EDT
Thomas,

gnome-terminal tries to be xterm compatible, and sofar the only
problem clearly defined seems to be the missing indn and rin
capabilities, which according to terminfo are new in xterm xf4.4.

Actually xterm also seems to not properly identify itself, since it
also has had major changes lately and still calls itself xterm.

So the question then becomes what should the default xterm terminfo
entry represent, the old xterm-r6 ? Which should work everywhere, or
the latest, greatest xterm-xfree which then breaks on older xterms and
gnome-terms?

I really don't want to have discussions about the principally best
fix, and much rather have a pragmatic fix which works.

So my proposal to fix this is to make the terminfo xterm entry
represent the latest and greatest xterm as much as possible without
breaking compatibility with older xterms and with xterm clones.

On the other hand fixing bugs in xterm clones of course also can't hurt.
Comment 47 Thomas E. Dickey 2004-07-15 12:26:18 EDT
Actually - though the terminfo for indn/rin is recent, the
code in xterm to support it dates back several years (1996 or
1997).  I added that because it made a nice test-case for ncurses.
Offhand, I don't recall a recent (past 4-5 years, when I introduced
the newer keyboard layout) change to the xterm terminfo which
wouldn't work on the older versions of XFree86 xterm.
Comment 48 Thomas E. Dickey 2004-07-15 12:36:14 EDT
Actually - though the terminfo for indn/rin is recent, the
code in xterm to support it dates back several years (1996 or
1997).  I added that because it made a nice test-case for ncurses.
Offhand, I don't recall a recent (past 4-5 years, when I introduced
the newer keyboard layout) change to the xterm terminfo which
wouldn't work on the older versions of XFree86 xterm.
Comment 49 Eido Inoue 2004-07-15 12:41:01 EDT
comment 39:

(addressing points in order)

o the latest gnome-rh9 entry does re-add the home/end so that home/end
work from gnome-terminal. i believe at the time you wrote that xterm
was simply restored to it's original entry without modifications to
the gnome-terminal
o point 2 should be addressed by the additions of home/end in the
terminfo for gnome-rh9
o i disagree with the attempt at creating a least-common-denominator
version of the terminfo. this would only work if
konsole/gnome-terminal were perfect supersets of xterm functionality,
which they're not. until they are, the logical choice would be to
accuratly identify the terminal and set TERM properly.

comment 42:
term.sh should only set TERM to gnome-terminal if it is in fact a
gnome-terminal. sshing into a box should set TERM to xterm.

comment 45:
gome-terminal can be identified through the COLORTERM env var, which
is what term.sh uses. If it sees a gnome-terminal identifier (and ONLY
when it sees this), it sets TERM to gnome. It leaves TERM alone to the
default value (xterm) if it senses neither a gnome-terminal nor a konsole.

comment 46:
re-iterating, i believe the best fix is to leave the terminfo.src
alone as much as possible (with the exception of gnome-terminal, which
according to comment 39, needs the home/end definitions... perhaps
this fix belongs UPSTREAM in terminfo.src). Rather than trying to
create one terminfo entry which pleases everyone, it seems more
pragmatic and reliable to accurately identify when gnome-terminal and
konsole are used, and set TERM appropriately. In all other cases TERM
will be left alone.

(term.sh actually doesn't belong in /etc/profile.d but later than this
(/etc/bashrc perhaps... discoussing with notting), because the
COLORTERM doesn't get set during the profile read, but after)
Comment 50 Eido Inoue 2004-07-15 12:47:10 EDT
*** Bug 127926 has been marked as a duplicate of this bug. ***
Comment 51 Kaj J. Niemi 2004-07-15 13:59:55 EDT
Adrian,

Forcing users to create workarounds to obtain desired functionality
(eg. working termcap on another system) by having them set TERM=xterm
when sshing from a gnome-terminal window to another system will just
make FC3+ (and later RHEL4) stand out from the crowd in a negative way.

People expect gnome-terminal to work out of the box like a. xterm or
in some cases b. "the thing I access application X on server Y with".

This also creates a problem for people who have, say, 5K users who
suddenly start reporting degradation in functionality they expect.

Please reconsider. :)
Comment 52 Sammy 2004-07-15 14:26:37 EDT
I agree....as a user I should not have to do anything! If you can integrate 
your suggestion to all the applications that are effected by the above 
change so that the transition is seemless, than be my guest. BUT after 
installing new KDE packages I should not have to go into /etc/profile.d 
and change something. How many users know about environment 
variables.  
 
We keep going through this problem at least once a year: 
 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115448 
 
either all the fedora/redhat community get together and resolve the 
problem or just keep patching 
Comment 53 Eido Inoue 2004-07-15 15:02:07 EDT
Comment 51: I understand your point about "expect[ing] gnome-terminal
to work out of the box like a. xterm", but this bug isn't about
gnome-terminal's deficiencies-- it's about ncurses. I think the
fairest thing to do is when TERM is set to "xterm", it really /is/ xterm.

the advantage to keeping terminfo.src's xterm "pure" and using a
terminal-detector such as term.sh that runs upon virtual terminal
launch is as follows:

o People using pure/true xterm connecting to fc/rhel boxes will get
the pure xterm definition-- without any baggage/workarounds that may
(but may not) interfere-- without setting any env vars.
o People using gnome/konsole connecting to fc/rhel boxes will get a
definition appropriate for their weird little terminal (that we've
standardized on)-- without setting any env vars.

The only disadvantage as far as I know:

o for people sshing from gnome-terminal/konsole onto a box that DOES
NOT use ncurses' terminfo and/or does not have a gnome/konsole entry--
these people will need to set their env var to "xterm" and file bugs
against gnome-terminal/konsole when their term does not behave in a
xterm compatible way.

Comment 52:

the only case where you would need to do anything would be is in the
last case i mentioned above-- a gnome-term/konsole user sshing into a
alien un*x box that doesn't use ncurses' termcap/terminfo. These
people, and only these people, would need to change their TERM to xterm.

you're right about hitting this problem again and again. it's time to
stop kludging the terminfo to make up for gnome-terminal/konsole's
differences/weaknesses (despite their strengths)

there are too many terms out there that think they are "xterm"
compatible that are going to be sshing into fc/rhel boxes. mucking
with the default xterm definition is only going to get you into
trouble with these people.

People that want to run "gnome-terminal/konsole, etc." as a "xterm"
and find problems when they do need to file a bug against their
terminal, not against ncurses. I wish it was 100% compatible, but
unfortunately, it's not-- and it's not ncurses' problem if the xterm
definition is correct.

Granted, it IS ncurses' problem if the definition for gnome-terminal
is incorrect. That has been pointed out (the Home/End problem), and
has been corrected.
Comment 54 Kaj J. Niemi 2004-07-15 15:49:13 EDT
Adrian,

Regarding Comment #53: if people have been using TERM=xterm in
gnome-terminal and, for example, syntax coloring in vim they'll get
ansi control codes on the screen with ncurses-5.4-10 while in
ncurses-5.4-8 the screen looks all nice and dandy. 

I would be happy if xterm was synonymous with xterm-color.. OB-)

Comment 55 Eido Inoue 2004-07-15 16:56:43 EDT
comment 54:

vim is an important application, but the solution again is not to
change terminfo to compensate for an errant app-- vim should be fixed
so that it behaves properly (vim has a lot of internal tricks and
termpcap entries and it's trying to override/overcompensate).

if we start getting near a code freeze point, i'll obviously need to
unfortunately look at a hack as vim is too important to leave broken
(even if it is vim's fault), but for now, I'm going to stay with my
position that vim should be fixed to behave rather than terminfo be
massaged to compensate for vim.
Comment 56 Hans de Goede 2004-07-16 09:05:48 EDT
Comment 49:
-Fixing gnome-rh9 in terminfo (which at its own is a good thing todo)
still leaves the problem that gnome uses xterm terminfo entry to
determine which esq-sequences to send for home,end (and other keys)
but now identifies itself to applications as gnome.
-Comment 42 talksabout sshing out, not in

Comment 53:
You're hitting the nail right on its head here, there are going to be
a lott of people using other os's / distros sshing into FC boxes, but
this won't just work with the default terminfo xterm entry (see for
example the vim bug, most of the other os's/distros wil also have
gnome-terminal/konsole but these won't properly identify themselves,
since they don't have term.sh. And even if they do get term.sh / or
gnome-terminal is "fixed" to identify itself as gnome, their will
still be problems for all the older verions out there (including FC1,
FC2, RH9, RHEL3.

Also as you say yourself sshing out to other or older OS/distro's will
be broken too.

So that only leaves local access and sshing from/to FC3 machines
working, creating a nice FC island, if that iswhat we want I'll start
using M$ again.

We've had things working reasonable well for years, and as shown by my
second patch, we can still have things working well. Without al the
breakage described above, by just keeping things as they were.

I've been a RH user since 3.x and I must say that I've never feeled
less involved, then since RH has started this community oriented devel
process. If you read al the comments here it is clear that most users
want something which works in all scenarios not in 2 (and I say 1) out
of three scenarios)
Comment 57 Eido Inoue 2004-07-16 17:06:29 EDT
Marking this bug as CLOSED. The new ncurses with the corrected
home/end in the gnome terminfo entry corrects the problem described in
the "summary" of the bug.

o After talking with both the gnome-terminal/vte maintainer and the
upstream ncurses maintainer
   - I am rejecting the notion of patching the "xterm" entry, which I
am convinced is correct and should remain true to the source and
something we should've done long ago. Fedora is the place to look
forward, not hold on to broken behavior of the past. If you can get
the patch to be accepted upstream (ncurses tarball), that is another
matter...
   - I am open to the idea of patching non-"xterm" entries such as
gnome, konsole, etc. Those patches should also be submitted upstream
to ncurses if they affect all distros.

o Arguments about gnome-terminal/konsole not working against the
"xterm" definition belong in bug reports filed against gnome-terminal,
vte, konsole, etc.

o Arguments about vim not working belong in bug reports filed against vim.

o Arguments about TERM not being set correctly /probably/ belong in
bugs filed against component setup, as that's where the term.sh code
will go. (either in profile or in bash... RHEL3 and FC2 gnome-terminal
behave differently in these respects)

o and finally, I invite arguments about feeling "less involved ... "
with the "community oriented devel process" and about what "most users
want" to transfer this argument to fedora-devel-list@redhat.com
(despite comment 40).

As for the arguments about "their will still be problems for all the
older verions out there (including FC1,FC2, RH9, RHEL3)" which would
"creating a nice FC island", I fail to see supporting users that
refuse to update their boxes (with automated tools such as
up2date/yum, or in the case of end-of-life RHL9, manually) as a
problem worth solving, especially since we can control & push updates
(such as the term.sh addition) to those distros.

And furthermore, by keeping "xterm" pure, we're actually opening up
the so-called "island"-- real xterm users on un*x boxen get a
predictable and true xterm definition when they log into a FC/RHEL box.

Also, I am skeptical about the claimed inconvenience of having to
change terminal related settings (TERM etc) etc to make things work
with older/alien boxen only applies to terminfo because of this
reason: FC1 went full UTF-8 (RHL9 was UTF-8 for western euro only)--
which is a radical leap in functionality that breaks when connecting
to/from 8-bit single byte distros (still the majority). In other
words, users are still going to have to flip a whole lot of other
things (the codeset in gnome-terminal, the locale settings within the
session) from their FC (and RHEL4) defaults to "legacy modes" before
they're going to get a decent text mode experience with older (and
non-updated) boxes.

FC has always been about minimalizing patches (especially kludges,
which is what patching xterm to work with non-100% xterm compatible
terms is) and looking towards the future (which is fixing vim, and
fixing gnome-terminal-- and until they're /really/ xterm's and not
just wanna-bes, you set TERM to identify them as wanna-bes)
Comment 58 Hans de Goede 2004-07-17 01:19:00 EDT
Havill,

Thanks for the clear position, and for taking the time to answer.  I
wasn't aware that one of fedora's policies was to create an as much
unpatched distro as possible.

I'll try and take a look at your patches and create new bugzilla
entries where appropiate using the components as described above.
Comment 59 Hans de Goede 2004-07-17 02:29:09 EDT
I know I just said I would create new bugzilla entries, but this so
called fix, breaks a lott, so for convienence I'm entering things
here, just lett me know if you want this in a new bug:
1) As warned for a couple of times, gnome-terminal uses the xterm
 terminfo to decide which esc-sequences to send for home and end.
 Since the new xterm terminfo entry has no entries for khome and kend,
 it falls backs to it defaults, which are ESC O H for home and
 ESC O F for end. The new ncurses-4.5-10 however, has khome and kend
 entries for gnome which contain ESC [ 1 ~ and ESC [ 4 ~. Thus the
 orignal problem stil isn't fixed.
2) The latest setup....rpm in rawhide doesn't contain term.sh
3) The new ncurses-4.5-10 has no entries for khome and kend, causing
 the problems as described in this bug with less, for xterm itself
 too. IMHO this is not acceptable!
4) Starting mc in a real xterm gives:  *** err [lib/liblow.c(268)]:
 strncmp/isdigit/consolename failed
5) mc now things xterm is a dump terminal and asks for press any key
 to continue after every command executed
6) the ESC sequences send by F1-F4 by a real xterm don't match
 those in terminfo, this will brake apps!
7) if you do export TERM=xterm-xfree86 to fix 3-6, home and end don't
 match  terminfo, since these are mapped to ESC [ 1 ~ instead of
 ESC [ H in the XTerm appdefaults file, this needs to be fixed by
 taking out all the keybindings in the appdefaults file,
 I don't know if you can yank out the scrollwheel bindings too,
 since I don't have a scrollmouse to test.
8) in the real xterm backspace is mapped to CTRL-H in terminfo,
 but is mapped to asc-del (\177) or CTRL-? in the XTerm appdefault 
 file by the: "*VT100*backarrowKey: false" line.
9) if you fix 8 by removing the trouble making line from the XTerm 
 app-defaults, Emacs users will become unhappy since pressing
 backspace gives them their helpscreen.

1-2 should be easy to fix
3-6 are there because xterm in terminfo now uses xterm-r6, this could
 be fixed by making xterm teerminfo use xterm-xfree86. But afaik you
 don't want that. Another fix is to make xterm report itself as 
 xterm-xfree86, by putting a: "*termName: xterm-xfree86" line in the
 XTerm appdefaults.
7-8 can be fixed by removing most of the modifications to the XTerm
 appdefaults.
9 is an emacs bug, not a ncurses or terminal problem.

Well thats what a quick scan of gnome-terminal and xterm has found me
sofar. I'll try konsole next, do some more testing and report it all here.
Comment 60 Hans de Goede 2004-07-17 02:41:39 EDT
Additonal note, it might be a good idea to lett term.sh only muck with
TERM if TERM equals xterm.
Comment 61 Hans de Goede 2004-07-17 03:45:04 EDT
Created attachment 101993 [details]
new term.sh incorperating suggestion made in comment 60
Comment 62 Hans de Goede 2004-07-17 04:07:53 EDT
A quick scan of konsole has found me the following problems:
-no terminfo entry for backspace, home and end
-the ESC sequences for F1-F5 are wrong
Comment 63 Hans de Goede 2004-07-17 04:09:44 EDT
Created attachment 101995 [details]
patch fixing problem1 in comment 59 and all problems in comment 62

I've got todo some other stuff now I'll write a patch for the XTerm appdefaults
fixing 3-8 in comment 59 tomorrow.
Comment 64 Hans de Goede 2004-07-17 07:04:39 EDT
Some more thougts:
-all the changes we do to terminfo need to be mirrored to termcap.
 Actually I believe termcap as such should not be a package, and
 /etc/termcap should be a part of ncurses so that they can't get out of 
 sync.

p.s.

Since there are still some problems with this bug, and since the
original bug still is there, I believe this bug should be reopened.
Comment 65 Thomas E. Dickey 2004-07-17 07:25:23 EDT
I have a to-do item to update (and fill in missing information)
for the "gnome" terminfo entry, in ncurses.  Once that's done,
there should be no reason why gnome-terminal cannot use that.
Comment 66 Hans de Goede 2004-07-17 17:00:41 EDT
Thomas,

Following the path we now have choicen I fully agree, my patch is just
a quick fix for the most obvious problems for now. Beware though of
the fact that gnome-terminal determines how to behave partly on the
xterm terminfo entry, so what should be in the gnome terminfo entry
depends on what the xterm terminfo entry contains.
Comment 67 Thomas E. Dickey 2004-07-17 19:56:11 EDT
The differences should be smaller now - see
ftp://invisible-island.net/ncurses/terminfo.src.gz
Comment 68 Hans de Goede 2004-07-18 05:03:31 EDT
Thomas,

I took a quick look remarks sofar:
-gnome terminal can send F1 and F10, you can unbind them from the menu
 somewhere in the options / preferences. If you do this they work
 just as xterm's
-konsole by default uses the konsole-xf4x keyb layout, not 
 konsole-linux
-konsole sends the same ESC-sequences for shifted F-keys as xterm
 does, and I've submitted a patch upstream to also make it send
 the xterm ESC-sequences for the ctrl and alt modifiers which it 
 currently ignores. I would like to see konsole-xf4x using 
 xterm-pc-fkeys, this will work for the shift modifiers right now and
 also prepare ncurses for the patch I've submitted (which hopefully 
 will get applied)
Comment 69 Hans de Goede 2004-07-18 05:57:01 EDT
Created attachment 102012 [details]
patch taking terminfo.src to the version given by Thomas Dickey in comment 67
Comment 70 Hans de Goede 2004-07-18 05:58:50 EDT
Created attachment 102013 [details]
patch fixing the problems mentioned in comment 68, this one should be applied on top of the previous one

For konsole this patch also maps kbs to \177 instead of ^H, since that is what
the current konsole does.
Comment 71 Thomas E. Dickey 2004-07-18 06:26:19 EDT
Testing konsole on Debian yesterday, I did not see it respond to
any modifiers other than shift.  I made a to-do note to make a
reduced description for it, but xterm-pc-fkeys does not apply to
the version of konsole I was testing.

(I wasn't sure if konsole-xf4x was the default, or whether Debian
had customized it - likewise the ^H/^? choice - intended looking at
the upstream source to get a definitive answer).

It would be nice if gnome-terminal and konsole's changelogs reflected
the places where they copy functionality from xterm (so far I've
found the changelogs and documentation to be useless).
Comment 72 Hans de Goede 2004-07-18 07:09:08 EDT
I can't find any patches changing konsole's behaviour in the kdebase
src.rpm so I assume that kbd=\177 and the xf4x layout are the upstream
defaults, since thats the behaviour I have on my FC3 test system.

You're right that currently konsole only uses the shift modifier, I've
modified my patch to reflect this, since I'm not sure that my konsole
patches are going to be excepted upstream, and because my patches
don't support combined modifiers and thus need rewriting.
Comment 73 Hans de Goede 2004-07-18 07:10:55 EDT
Created attachment 102014 [details]
patch fixing the problems mentioned in comment 68 updated to reflect the problems with this patch mentioned in comment 71, this one should be applied on top of the terminfo.src update
Comment 74 Hans de Goede 2004-07-18 08:29:39 EDT
Created attachment 102015 [details]
improved patch fixing the problems mentioned in comment 68 updated to reflect the problems with this patch mentioned in comment 71, this one should be applied on top of the terminfo.src update

My last patch (comment 73) redefined F10 - F12, without this being nescesarry.
This version cleanes this up.
Comment 75 Thomas E. Dickey 2004-07-18 09:57:03 EDT
Checking the upstream source, it appears that only the vt420pc
flavor of konsole uses ^H.  Also, it appears that the default
(upstream) keyboard setting is the XFree86 4.x.x (for some time -
so it's likely I was seeing a local customization before).
Comment 76 Hans de Goede 2004-07-18 11:39:33 EDT
Hmm,

Using TERM=xterm-xfree86 and a fixed appdefaults to fix problems 3-8
in comment 59 causes the following problem:

When opening a textfile in joe the first character of some lines is
missing. Joe does know that it should be there, pressing ends moves
the cursor one position past the last char of the line, but for some
reason the first char isn't displayed and the rest of the line is
shown shifted one char to the left.

Using TERM=xterm-xf86-v43 makes this problem go away.

Thomas do you have any thoughts on this?
Comment 77 Thomas E. Dickey 2004-07-18 11:49:01 EDT
Are you using gnome-terminal?  Wrapping behavior is one of the
places where gnome-terminal doesn't match (anything except
konsole).

Only last week I got mail from someone asking me to bless it.
There's a demo script in
    ftp://invisible-island.net/temp/my_eol
which may show the same sort of thing.
Comment 78 Thomas E. Dickey 2004-07-18 13:05:44 EDT
Another thought - I've noticed in the past week or so that my
shells are omitting (in some cases) the first character of the
input from the display.  Other than seeing that if I change $TERM
to xterm-xf86-v44 that fixes it, I haven't pinpointed the problem.
It could either be another symptom of the workaround I've made for
tgetstr("me") versus Debian #254316, or another issue undetermined.
If it's the same as #254316, the problem will go away with the
next update for ncurses.  (I'm normally running screen, which would
be affected by the same problem, but recompiled that w/o otherwise
modifying my shared ncurses libraries so I could look for other
impact of that bug).
Comment 79 Robert Scheck 2004-07-18 13:18:37 EDT
Correcting, Thomas, I think you meant 
  ftp://invisible-island.net/temp/my-eol
because that is the onliest similar reachable file ;-)
Comment 80 Thomas E. Dickey 2004-07-18 13:46:45 EDT
yes.  Anyway, there are two that come to mind, depending how
I read your comment.
Comment 81 Hans de Goede 2004-07-18 17:11:23 EDT
Thomas,

The first char missing problem is with the real xterm. That's why I'm
using TERM=xterm-new, to fix all the problems you get with the real
xterm when using TERM=xterm (which is the same as TERM=xterm-r6)

It sounds to me like it the same problem you're having with the first
char missing on the cli.

I just tried using TERM=xterm-xf86-v44 and that fixes it (so does
TERM=xterm-xf86-v43)

Could you give a pointer to this new ncurses which you are talking
about, then I can see if that indeed fixes it. Maybe FC3 should use
the terminfo.src shipped with ncurses, with just a few minimal patches
applied, since your new version seems to break other stuff.
Comment 82 Thomas E. Dickey 2004-07-18 18:07:36 EDT
That's only in source - my rollup patch at
   ftp://invisible-island.net/ncurses/5.4/patch-5.4-20040711.sh
for instance.  The particular file that changed happens to
be one that hadn't changed recently:
   ncurses/tinfo/lib_termcap.c
so it would be possible to update just that file.  To make it
simple, see
   ftp://invisible-island.net/temp/lib_termcap.zip

The difference that matters in the terminfo are the rmacs, smacs,
enacs, sgr and sgr0 strings.  The lib_termcap.c code filters
the sgr0 string, as I noted in the Debian bug report.

I just installed up-to-date libraries over Debian's, to check if
that fixes things as well - they're upward-compatible as far as
I know.
Comment 83 Hans de Goede 2004-07-19 04:19:09 EDT
Thomas and Havill,

I've tried Thomas' ncurses patch, upgraded with to the newer
terminfo.src he has pointed out earlier with my konsole and gnome
patches applied. This does indeed fix the first char on a line missing
problem, but this has problems with lines which are longer then 1 line
and thus need to be wrapped, this goes "funky" both on the bash prompt
and in joe.

So I have abandoned the new terminfo.src, and instead just took the
gnome and konsole entry changes from the new terminfo.src, and fixed
the problems with these described in comment 68 and 70. If I've
understood Thomas correct he agrees with these fixes. I'll attach a
patch for Thomas' gnome and konsole updates with my fixes integrated.

I've done some more testing and I can't find any regressions with the
plain ncurses-5.4 terminfo.src with just this patch applied, using
term.sh and making the nescesarry changes to xterm app-defaults. This
goes for xterm, gnome-term and konsole. 

May I suggest applying my (latest) patch instead of the current broken
home_end patch and closing this bug once and for all.
Comment 84 Hans de Goede 2004-07-19 04:30:35 EDT
Created attachment 102025 [details]
tarball containing dirs with patches to either fix plain ncurses-5.4, or to take it to the latest ncurses-snapshot and terminfo.src and then fix it
Comment 85 Hans de Goede 2004-07-19 04:49:45 EDT
I made a booboo (once again) The long line problems are with the
latest terminfo xterm-new entry, but I was still using a plain (old)
FC2 xterm. These problems go away by upgrading xterm to the FC3-test1
release.

Still I think just applying a minimal set of fixes to plain
ncurses-5.4 is the best approach, since the snapshot version are just
that: snapshots.
Comment 86 Hans de Goede 2004-07-19 05:18:13 EDT
Created bug 128138 for the needed xterm appdefaults changes
Comment 87 Thomas E. Dickey 2004-07-19 05:19:10 EDT
odd - I don't recall any changes to xterm itself that would
affect line-wrapping.  I'll have to find more about that.
I seem to recall that fc2 xterm is patch #179 - is that right?
A couple of typescript files (from 'script') running the good
and bad cases for the long bash prompt might show me what's
actually happening.
Comment 88 Hans de Goede 2004-07-19 08:49:28 EDT
Forget I ever said that, FC2 indeed ships with xterm-179 and I just
downgraded to this and I can't reproduce the problem.

Maybe I had TERM set to something funky I have been experimenting so 
much with this stuff that I appearently did something weird.

Right now I can run the latest ncurses snapshot with the latest
terminfo.src applied over it with my fixes to gnome-terminal and
konsole on top of it and it works just fine with xterm-179 and xterm-192.
Comment 89 Thomas E. Dickey 2004-07-19 09:27:33 EDT
good (I'm of course interested if there's a problem that we can
reproduce, but don't recall any new problems with the current
ncurses snapshot - just a number of unfinished details)
Comment 90 Eido Inoue 2004-07-19 10:18:14 EDT
Created attachment 102035 [details]
slightly tweaked term.sh

Same as the term.sh proposed with comment 60, except surround $TERM in double
quotes so that an unset TERM doesn't cause the script to fail with a syntax
error.
Comment 91 Hans de Goede 2004-07-19 10:25:49 EDT
I felt that one ("" around $TERM) coming about two minutes after I had
attached my term.sh :)

One last note, if you're going to use the ncurses snapshot and/or the
updated terminfo.src: I just noticed that with the updated
terminfo.src from Thomas xterm now longer uses (points to) xterm-r6
but points to xterm-new.

Afaik you wanted xterm to point to xterm-r6, as it does with a vanilla
ncurses-5.4 terminfo.src. So if you're going to use the updated
terminfo.src don't forget to patch it to make xterm point to xterm-r6.
Comment 92 Thomas E. Dickey 2004-07-19 10:34:57 EDT
That's a configure option (--without-xterm-new).
Comment 93 Thomas E. Dickey 2004-07-24 10:37:45 EDT
btw, I'm not sure that term.sh will work properly with rxvt.
On my system for example, rxvt sets $COLORTERM to "rxvt-xpm".
Comment 94 Hans de Goede 2004-07-27 06:38:35 EDT
I'm seeing the same over here, suggested fix:
-change the if test $COLORTERM=gnome-terminal test to a case,
 then do the current gnome thing for gnome, do nothing for rxvt* and
 do the konsole thing for *
-even better would be to patch konsole to properly set COLORTERM, and 
 then only do the konsole thing when COLORTERM=konsole


Comment 95 Hans de Goede 2004-07-27 06:40:22 EDT
p.s.

When is this bugged going to gert really fixed? My patches taking just
the changes for konsole and gnome-terminal from the latest bleeding
edge ncurses/terminfo and intergrating these into terminfo from a
clean ncurses-5.4 are pretty straigtforward and safe IMHO.

And currently things are still broken in rawhide.
Comment 96 Thomas E. Dickey 2004-07-27 16:09:05 EDT
(I thought I saw a comment from Havill that he's on vaction til
August 1).
Comment 97 Eido Inoue 2004-07-27 16:15:00 EDT
no i'm still here. looking to push tonight after i test the rxvt and
COLORTERM
Comment 98 Hans de Goede 2004-07-31 03:45:36 EDT
5.4-11 looks very good, BUT currently TERM=xterm in terminfo is the
same as TERM=xterm-new, afaik you wanted that to be the same as
TERM=xterm-r6.

In order to get TERM=xterm to be the same as TERM=xterm-r6, add
--without-xterm-new to the %configure flags.

Comment 99 Robert Scheck 2004-07-31 10:28:39 EDT
5.4-11 works for only partially for me, but that isn't still 
enough...if I do "less <rpm-file>" for example, home/end works. But 
if I do "rpm2cpio <rpm-file> | less", there home/end doesn't work. 
This already worked with 5.4-7 for me...

FYI: I did this (reproducable) over a ssh connection and also at 
the konsole directly (ttyX).

Seems so, that a further fix is needed to solve this problem also.
Comment 100 Hans de Goede 2004-08-07 08:19:10 EDT
Ehm, your piping a binary file through less, who would want to do that?
Comment 101 Robert Scheck 2004-08-07 08:37:45 EDT
Hans, I didn't test piping text files through less yet, but I think 
when we try to solve this issue, we should do it completely and in the 
right way, otherwise we can fallback to the old non-working stuff... ;-)
Comment 102 Hans de Goede 2004-08-07 08:53:54 EDT
Binary data streams can contain anything, and thus also
control-esc-sequences which completly mess up the terminal.

Trying to display binary in a terminal us just ehm stupid.
Comment 103 Robert Scheck 2004-08-07 09:35:37 EDT
Well, I can't completely agree with you anyway, so THIS already worked 
with previous versions - why shouldn't it possible to make it here 
also working?!
Comment 104 Thomas E. Dickey 2004-08-07 10:50:23 EDT
A quick check of the output from less in the two cases
shows me that when you pipe to it, it simply cat's the
file's output until it gets something interesting (like
deciding that it's reached the end of the screen).  In
contrast, running from a file, it does some additional
filtering).  If you really need to cat binary files to
the screen, you should file a bug report against less,
since it is not doing what you want.
Comment 105 Sammy 2004-08-10 12:01:55 EDT
I would like to add a few comments for konsole users: 
 
1. Files /etc/DIR_COLORS and /etc/DIR_COLORS.xterm need to have 
    a line "TERM konsole". 
 
2. /etc/bashrc (setup-) that sets the window title is based on "xterm" 
    (fancy titles), one needs to modify this to do the same for konsole. 
    Of course if a remote system checks for xterm to set this and you 
    come in as konsole.... you are out of luck! 
 
Comment 106 Bill Nottingham 2004-08-10 12:06:23 EDT
And /etc/DIR_COLORS*... why isn't ls actually just using the
termcap/terminfo? 
Comment 107 Sammy 2004-08-10 12:15:08 EDT
You do get some color without the /etc/DIR_COLORS* but some things 
like files with .rpm extension etc. do not seem to get color while 
directories etc do appear in color. I don't  know why. 
Comment 108 Eido Inoue 2004-08-10 14:21:42 EDT
I'm going to remove the term.sh script for now after testing against
both current OSS apps (the term detect code for the xterm title bar in
bashrc for example) and proprietary apps. Too many apps check for
"xterm" and don't check for anything else. It's too bad terminal types
are similar to XML MIME types, were you can tell if a certain format
is XML based-- code is usually written to assume that if the TERM
isn't "xterm", then it must be completely 100% non-xterm compatible.

The current gnome-terminal seems to work with both gnome and xterm--
so long as the terminfo/termcap is not generated with
--without-xterm-new-- as home/end seem to fail to work against the
newest gnome-terminals.
Comment 109 Thomas E. Dickey 2004-08-10 16:15:05 EDT
Well, it would be nice if "ls" simply used termcap/terminfo
to decide if the terminal supports color (and got rid of the
constants).

Adrian's last comment confuses me: as I understand it,
gnome-terminal doesn't recognize the escape sequences used
in xterm-new for rin/indn.
Comment 110 Hans de Goede 2004-08-11 02:06:27 EDT
Wait a minute,

So now it has been decided that term.sh is going to be dropped, and I
was just starting to like the idea :|

But if you're going todo this then you will need to:
-modify terminfo.src so that the xterm entry:
 *explicitly tells not to habe rin/indn, since this breaks
  for example scrolling longer mails in mutt in gnome-terminal
 *probably best to make kbs be \177, instead of the xterm-new ^H,
  since \177 is what both konsole and gnome-terminal send
 *uses xterm-new
 *maybe Thomas is willing to make an xterm-compat terminfo entry for 
  this??
-modify the real xterm to send \177 for backspace (there is a
 resource setting for this)
-investigate the mutt line drawing problem you have mentioned in this 
 bug
Comment 111 Hans de Goede 2004-08-12 02:55:27 EDT
About my last comment: maybe I was a bit quick to suggest that
terminfo should be modified to reflect the fact that kbs sends \177
instead of ^H

On second thought it might be better to fix gnome-term and konsole
here to match xterm. Since xterm is the one and only real xterm.

We do still need to suppress the rin and indn capabilities though.
Comment 112 Pekka Pietikäinen 2004-08-17 08:51:21 EDT
Here's a datapoint that might be of interest. Although this only
happens with screen (and in fact only fc2 screen, fc1's seems fine) it
sounds like the same bug.

Basically solaris9 gnome-terminal (2.0.1), ssh to fc2 box,
start up screen (TERM=xterm), use tab command completion in bash -> 
text gets messed up like this:

it-gw13 (pp):/var/tmp >ls
nadvsh  sparse-bk  srss_3.0  srss_linux_3.0.tar
it-gw13 (pp):/var/tmp >ls srss_<3 x TAB>
and it changes to
it-gw13 (pp):/var/tmp >ls slinux_3.0.tar

TERM=xterm-xfree86 before screen -x and it's fine.
Comment 113 Thomas E. Dickey 2004-08-17 15:58:19 EDT
That appears to be an unrelated bug: rin/indn relate to
indexing (scrolling), and the example given would not use
that feature.
Comment 114 Bill Nottingham 2004-08-20 14:59:44 EDT
*** Bug 105781 has been marked as a duplicate of this bug. ***
Comment 115 Robert Scheck 2004-08-24 13:51:47 EDT
With a current Fedora Development system neither "End" nor "Pos1" is 
working - tested over ssh and terminal directly.
Comment 116 Robert Scheck 2004-09-01 14:01:09 EDT
Created attachment 103352 [details]
ncurses-5.4-color_xterm.patch

*grmpf* with the latest ncurses-5.4-13 from Development I've got the same
problem further on as already for an older ncurses version described before in
comment #115. For my personal use, I merged Hans de Goede's original patch from
comment #5, which still works for me (maybe because I don't use GNOME?!
*smile*). I attached it here, maybe someone wants to use it and don't want to
re-merge it ;-)

I'm still curious whether we get this problem solved - more or less - elegant
some day ;-)
Comment 117 Hans de Goede 2004-09-24 16:43:44 EDT
Since it is bug squash week, can we please finally fix this one?
Comment 118 Bill Nottingham 2004-09-24 23:38:09 EDT
*** Bug 132817 has been marked as a duplicate of this bug. ***
Comment 119 Bill Nottingham 2004-10-01 19:22:47 EDT
*** Bug 134300 has been marked as a duplicate of this bug. ***
Comment 120 Penelope Fudd 2004-10-07 16:26:42 EDT
I submitted Bug 134300, and when it got marked as a duplicate of this
bug, I came here.  After reading everything up till now, I have to
admit that this is a big hairy problem.

To summarize my bug:  Fresh install of FC3-test2, graphical log in to
gnome, start gnome-terminal from the menu, start lynx to an ftp site,
navigate around a bit, get a mangled display.  vim similar problem. 
^L fixes.  

Initially, I thought "Hey, why doesn't gnome-terminal just say
TERM=gnome-terminal?"  Problem: no such terminfo/termcap entry.  Ok,
how about gnome-terminal setting TERM=gnome?  Problem: no such
terminfo/termcap entry on other systems, as pointed out by
notting@redhat.com.

My solution: A similar solution to what was posted here: a term.sh
hack that says if COLORTERM=gnome-terminal and TERM=xterm, set
TERM=vt100.  I use vt100 because it makes the problems go away, it's
available on other unixes, and I'm pretty confident that it hasn't
been touched by anybody trying to "improve" things.  Note: I don't use
function keys or any cursor keys beyond the four arrows, which may
explain why I'm fine with vt100.

Oh, and offtopic: the backspace key has always been a problem... ^H or
^? ?  Fortunately, tcsh takes both.  Unfortunately, when I looked
last, it didn't set stty, so programs could still get it wrong.  I
think I've got it fixed in my startup scripts, but *man* that's a
problem that wouldn't be missed.

Thanks, and keep up the good work!
Comment 121 Robert Scheck 2004-10-08 12:41:24 EDT
Is it possible, that we solve this issue up to Fedora Core 3 in a 
fine way?! Today, I had to work with a SuSE Linux 9.1 and I noticed, 
that they have the same problem... ;-)
Comment 122 Johnny Mnemonic 2004-10-17 10:10:48 EDT
Sorry for stepping in late in the discussion. I hope my feedback will
be someway useful.

I'm using a fully updated FC2 remotely, without even X11 installed. I
connect to it remotely via SSH and I get TERM=xterm from a RedHat9.
My home/end keys doesn't work in mutt and setting TERM=linux fixes the
problem.
Comment 123 Eido Inoue 2004-11-03 16:32:41 EST
re-tested with latest rawhide FC3 and confirmed working
pgup/pgdown/home/end in less on xterm/console/gnome-terminal/konsole
Comment 124 P Fudd 2004-11-04 02:40:08 EST
Does this fix the additional problem about display corruption in
'lynx' and 'vim' with TERM=xterm and gnome-terminal?

If not, then please undelete Bug 134300.  Thanks!
Comment 125 Hans de Goede 2004-11-05 09:53:01 EST
I've been doing some intensive testing /research related to this bug,
the results:
-ncurses/terminfo now seems 100% ok.
-gnome-terminal has some inconcistencies with terminfo and the real
 xterm reported upstream:
 http://bugzilla.gnome.org/show_bug.cgi?id=157448
-konsole has some inconcistencies with terminfo and the real
 xterm reported upstream and to RH:
 http://bugs.kde.org/show_bug.cgi?id=92749
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138191
-xterm should not identify itself as xterm-new see my latest comment:
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128138
Comment 126 John Thacker 2006-04-28 09:40:19 EDT
*** Bug 121922 has been marked as a duplicate of this bug. ***