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):
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
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...
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
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.
*** Bug 124039 has been marked as a duplicate of this bug. ***
This is a particularly annoying bug. Affects mutt, nano, less...
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
* letts hardcode a link of TERM=xterm to TERM=gnome-rh9 in terminfo
* 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
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
-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.
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
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!
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?
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
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.
That sounds like a problem reported elsewhere (one
of the bugs in gnome-terminal).
see for example
(I tried a while ago to subscribe,
but that website is mildly broken).
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
The real fix is to use the terminfo entry that I made for
gnome-terminal (which doesn't use features that it doesn't
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).
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 ?
As promised I've created a patch fixing the home and end keys in
konsole, see bug 124803
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.
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.
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;
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;
sgr0: '\E[m', '\E[m\017'.
smcup: '\E7\E[?47h', '\E[?1049h'.
tbc: NULL, '\E[3g'.
vpa: NULL, '\E[%i%p1%dd'.
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
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.
I'm not sure how to interpret Job's comment (it doesn't say what
terminfo entry he was actually using).
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.
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.
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 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
*** Bug 123987 has been marked as a duplicate of this bug. ***
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
Created attachment 100794 [details]
Patch fixing the original problem and the bug reported in comment 9
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.
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?
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...
*** Bug 125881 has been marked as a duplicate of this bug. ***
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.
what's the status of fixing this annoying issue?
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.
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.
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
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 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 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
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
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
Reopening, because the latest proposed solution doesn't really solve
the original problem, thank you Hans.
Uh, setting TERM=gnome breaks just about every remote system I have
access to. Solaris, HP-UX, FreeBSD, etc. systems do not know anything
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
-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
Marked as FC3 target bug. Well, again, the latest available update
packages don't really solve the issue for me, awaiting response from
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).
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
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.
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.
(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
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.
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.
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.
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)
*** Bug 127926 has been marked as a duplicate of this bug. ***
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. :)
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
We keep going through this problem at least once a year:
either all the fedora/redhat community get together and resolve the
problem or just keep patching
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.
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.
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-)
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.
-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
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)
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
- 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 email@example.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
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)
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.
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)]:
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
7-8 can be fixed by removing most of the modifications to the XTerm
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.
Additonal note, it might be a good idea to lett term.sh only muck with
TERM if TERM equals xterm.
Created attachment 101993 [details]
new term.sh incorperating suggestion made in comment 60
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
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.
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
Since there are still some problems with this bug, and since the
original bug still is there, I believe this bug should be reopened.
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.
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.
The differences should be smaller now - see
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 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)
Created attachment 102012 [details]
patch taking terminfo.src to the version given by Thomas Dickey in comment 67
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.
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).
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.
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
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.
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).
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?
Are you using gnome-terminal? Wrapping behavior is one of the
places where gnome-terminal doesn't match (anything except
Only last week I got mail from someone asking me to bless it.
There's a demo script in
which may show the same sort of thing.
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).
Correcting, Thomas, I think you meant
because that is the onliest similar reachable file ;-)
yes. Anyway, there are two that come to mind, depending how
I read your comment.
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
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.
That's only in source - my rollup patch at
for instance. The particular file that changed happens to
be one that hadn't changed recently:
so it would be possible to update just that file. To make it
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
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.
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
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
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
Created bug 128138 for the needed xterm appdefaults changes
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
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.
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)
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
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.
That's a configure option (--without-xterm-new).
btw, I'm not sure that term.sh will work properly with rxvt.
On my system for example, rxvt sets $COLORTERM to "rxvt-xpm".
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
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.
(I thought I saw a comment from Havill that he's on vaction til
no i'm still here. looking to push tonight after i test the rxvt and
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
In order to get TERM=xterm to be the same as TERM=xterm-r6, add
--without-xterm-new to the %configure flags.
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.
Ehm, your piping a binary file through less, who would want to do that?
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... ;-)
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.
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
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.
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!
And /etc/DIR_COLORS*... why isn't ls actually just using the
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.
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
Well, it would be nice if "ls" simply used termcap/terminfo
to decide if the terminal supports color (and got rid of the
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.
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
*maybe Thomas is willing to make an xterm-compat terminfo entry for
-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
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.
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.
That appears to be an unrelated bug: rin/indn relate to
indexing (scrolling), and the example given would not use
*** Bug 105781 has been marked as a duplicate of this bug. ***
With a current Fedora Development system neither "End" nor "Pos1" is
working - tested over ssh and terminal directly.
Created attachment 103352 [details]
*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 ;-)
Since it is bug squash week, can we please finally fix this one?
*** Bug 132817 has been marked as a duplicate of this bug. ***
*** Bug 134300 has been marked as a duplicate of this bug. ***
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.
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
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!
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... ;-)
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
re-tested with latest rawhide FC3 and confirmed working
pgup/pgdown/home/end in less on xterm/console/gnome-terminal/konsole
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!
I've been doing some intensive testing /research related to this bug,
-ncurses/terminfo now seems 100% ok.
-gnome-terminal has some inconcistencies with terminfo and the real
xterm reported upstream:
-konsole has some inconcistencies with terminfo and the real
xterm reported upstream and to RH:
-xterm should not identify itself as xterm-new see my latest comment:
*** Bug 121922 has been marked as a duplicate of this bug. ***