From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: Programs using terminfo correctly (e.g., ne) won't work correctly in Fedora 3. The terminfo data for xterm has been changed from Fedora Core 2, and now kbs is ^H instead of \177 (the right key). Every application that processes keys correctly will have problems, as the default meaning of \177 should be delete, not backspace, so the Delete and Backspace key will perform the same function (Delete). There may be applications that cheat or guess what to do, but this is not the point--applications using correctly terminfo will break. I am the author of the Backspace-Delete HOWTO, which I thought was by now completely obsolete. This is the first release since years that breaks Backspace/Delete again. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run ne (the RPM is on DAG). 2. Use backspace and delete. Additional info: The simple fix: infocmp >xterm.ti [edit xterm.ti setting kbs to \177] tic xterm.ti That's it.
kdch1 is \177 kbs is ^H That hasn't changed in ncurses or xterm for several years.
No, in all my Fedore Core 1 & 2 installations kbs=\177 and kdch1 is the usual escape sequence. In all Fedoras, kdch1=\E[3~. Check it out: infocmp xterm | grep kdch1
Right about kdch1, wrong about kbs (if you're seeing it as anything but ^H, that's a Redhat customization - I'm reporting what ncurses and xterm have in the change history).
With FC3 RH decided to drop all RH customizations from ncurses and xterm. Which on itself was a good thing todo. But this has created this problem, as T.E. Dickey has written upstream ncurses and xterm have used ^H for backspace for years. Somewhere in the 5.x/6.x days RedHat decided to follow the Debian keyboard guidelines which say, that backspace should always send ASCII-del (\177), this was and is a Debian custimazation and not something done upstream. Note the decission to follow the Debian keyboard guidelines was partially made under my influence as I was a betateam member at that time and have done a lot of testing and patches to get consistent keyboard behaviour in textmode. After this bit of history on to the current problem. As reported ncurses now contains the upstream default of ^H for backspace, but the terminal used by the reporter sends ASCII-del. This means that the reporter is not using xterm as xterm shipped with FC3 uses the upstream default of ^H, but is probably using gnome-terminal or konsole since these both send ASCII-del for backspace. So the question is does RedHat still want to follow the debian keyboard guidelines for backspace in which case xterm and ncurses need patching, or does RedHat wants to use the upstream defaults for ncurses and "the real" xterm and patch gnome-terminal(libvte) and konsole to match the real xterm. I believe to remember a mail by someone at RedHat which said that RH still wants to follow the Debian keyb guidelines (Havill?), but I've also heared sounds that RH wants to stick to the upstream ncurses and real xterm and fix gnome-terminal and konsole, the latter seems to be the final conclusions of the discussions under bug 122815. Assuming that RH wants todo the latter (unmodified ncurses, make backspace send ^H) I've entered two bugs to fix konsole and gnome-terminal a long time ago: http://bugzilla.gnome.org/show_bug.cgi?id=157448 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138191 If RH however decides to follow the debian keyb-guidelines then this bug is valid and a bug for "the real" xterm needs to be opened. Peter (Rockai), this bug has been open since 12-11 and yet nothing has been done, could you please discuss this internally in RH (Havill?) and get a decission on wether RH is going to return to following the Debian keyb guidelines, or is going to stick with the official ncurses way (backspace = ^H). Fixing this is easy once the decission has been made! If the decission has been made I'm more then willing to write up all needed patches to fix this, iow I'll hand you the solution on a silver platter, but we need a decission first! Note: as the concensus above concludes delete is not a problem.
yes - it's awkward for me to change things like that, since (for example), the same definitions would ultimately apply to FreeBSD, which uses ^H.
mharris, I asked for help for the resolution of this bug on #fedora-devel, and twaugh responded that you might know what todo, so I'm adding you the the CC-list of this bug. The big question which stops this bug and a number of others of getting resolved is what character should the backspace key in a terminal claiming to be xterm send, ASCII-DEL or CTRL-H . T.E. Dickey the upstream ncurses (terminfo) and "the real' xterm maintainer says that it officially has been CTRL-H for ages and doesn't want to change this, but in the past RH has shipped patched versions which make xterm & friends send ASCII-DEL, following the debian keyboard guidelines. In FC3 things are a mess and I would like this issue decided upon so I can check all involved packages and get them consistent (as decided) for FC4. Thanks!
>So the question is does RedHat still want to follow the debian >keyboard guidelines for backspace Yes. The changes we previously made to xterm resources for this, were disabled when we disabled our resources patch. The intention was to find out which of the changes were still really necessary, and to clean things up a bit, however due to time and resource constraints, xterm ended up not getting this patch re-enabled for quite some time. xterm in rawhide now once again has our resources patch enabled, and it has been tidied up a bit. We've removed things that we used to patch for that upstream xterm now has defaults that are the same or close enough. While it is definitely a very widly debated issue as to how the BS and DEL keys should work, I take the position that both groups are correct. That is to say that Backspace should work on an IBM PC keyboard, like users used to using IBM PC keyboards with other operating systems such as Windows and DOS, are used to Backspace working, which is to delete the previous character and move back one position, and the DEL key, on an IBM PC keyboard, should keep the cursor where it is, deleting the character under it, and pulling characters after it towards it. If that sounds confusing at all, I can simplify it by saying that BS key should work like it does in Microsoft Windows, and DEL should work as it does in Windows also. The reason for this decision, is that while both ways are "correct" depending on what type of keyboard you are using, and what computing background you are coming from, there can only be one single default. The user who does not know the difference, or even realize that there are different ways that BS and DEL might work historically on different computer systems, generally is going to be used to the Windows/DOS way that these keys work, and is not going to be comfortable with trying to reconfigure their system to do what they think it should do by default. Old school UNIX users, and others who are used to VAX terminals and other terminals however are much more likely to understand the intricacies of configuring this low level stuff, and are in a much better position to be able to understand the available options in the various different pieces of the puzzle, and to configure their system to work the way they are used to for UNIX historical or other purposes. So, the simple acid test is to install Fedora Core on a traditional IBM PC with a PC keyboard and normal standard off the shelf Walmart computer hardware basically, open a terminal on it, and type something. Press backspace and it should work like it does in Windows, press DEL and it should work like it does in Windows. If it does not, that is a bug, and we want to change it to make sure it does work like it does in Windows. As I mentioned above, I realize that some people's preferences are very much different from what our goal here is. Since it is not possible to have it both ways, a decision must be made as to how we want these keys to work in our OS, and we've decided that, and hope that everything works consistently throughout the OS with this stated goal. I believe this is part of the logic behind Debian's decision as well. Hope this helps clarify and understand the problem from our angle.
>hardware basically, open a terminal on it, and type something. Press >backspace and it should work like it does in Windows, press DEL and it >should work like it does in Windows. If it does not, that is a bug, and This is a tough problem. Years and years of similar issues have caused every application to apply a number of workarounds and patches. By now it is almost impossible to foresee (even with a correct setup!) what will happen. What I can tell for certain is the ne (the nice editor) does it in the right way, and does not try to make guesses. If it is set up correctly, it will work with ne. The only important thing, however, is that the terminal database agrees with the keys emitted by the terminal. The rest will follow (or you can complain mightly with whoever wrote the application 8^).
Harris, Thanks for taking a look at this and for the answer. I fully understand and agree that the keys should behave as under windows. But I wonder what is your answer, since you started your answer with: >So the question is does RedHat still want to follow the debian >keyboard guidelines for backspace Yes..... So was that a Yes as in Yes this is the question and then the long story to explain that there isn't an easy answer? Or Yes as in "Yes, RH still wants to follow the Debian keyboard guidelines" As explained I've currently been working on making konsole and gnome-terminal behave as the real xterm does, since that is what the claim to be, but this is NOT according to the Debian keyboard guidelines. Your whole explanation that the keys should behave as under windows is 100% correct and agreed upon, but doesn't help us to answer the question. For these keys to behave correct a couple of things are nescesarry: -terminfo and the terminal should agree on the sequences send by the keys -stty erase should be set to the sequence send by the backspace key -the application should either properly use terminfo (Note: dumb applications (f.e. less) will work fine as long as stty erase is ok) The first 2 criteria are what the discussion is about now, and as long as things match it can be either way and things will work as you (we) want. Combining this with the upstream upstream manta and Thomas E. Dickey's (upstream) clear vision on this I personally prefer ditching the debian keyb guidelines, following upstream xterm and ncurses(terminfo) and make xterm wannabees behave as the real one does.
The answer is basically that Red Hat wants to have what we had from about Red Hat Linux 5.0 or so onward to Fedora Core 1 or thereabouts, which is I believe in line with Debian guidelines. Our xterm is now doing exactly what it was doing before. If anything else in the mudpie has changed in any way from what it was before, it needs to change back, or otherwise bend and fit the common goal. What I want to totally avoid in the process, is receiving a stream of bug reports from people because something has changed and they don't like having to adjust to the change. That is why our xterm is using what it has always before. I will do whatever I can to avoid a maintenance or support nightmare. Our konsole and gnome-term maintainers hopefully will keep those terminals working similarly, however I'm not involved with maintaining those, so I don't really have much of an opinion about them. If by "upstream mantra" you are refering to my statements from before about wanting to keep xterm as close to upstream defaults as possible, perhaps I should clarify things a bit... gnome-term is our official "supported" terminal application, with "konsole" being second. "xterm" is provided more or less as-is, as many people are used to it and prefer it for historical reasons, or prefer its lower memory footprint, or have some other preferential reason for wanting to use xterm instead of our supported terminals. There are enough xterm users out there that the application is definitely quite relevant, and probably will be for quite some time. We prefer to focus our engineering resources on a smaller set of applications as that gives the biggest bang for the engineering buck. As such, we've been trimming the OS each release for some time now, to try to reduce the amount of duplicated functionality. Dividing our engineering resources between 3, 4, and sometimes 5 or more applications (such as email clients) all of which serve the same purpose, but differ in feature sets and specific functionality spreads our engineering resources thin, which results in smaller overall progress each OS release. The idea here, is by concentrating effort on a smaller set of applications, we get more overall progress each release. Some of the applications, such as xterm, which provide duplicate functionality however, are very widely used, and so dropping them from the OS just because they're not the officially supported terminal application would have too major an impact to the OS for many people who are used to it. We therefore include xterm in a more or less "as-is" state to minimize engineering and support overhead, but we balance that by providing occasional upstream bug fixes and other updates as time permits. This seems to be a healthy way of letting people have their cake and eating it too in practice, but without tying up much engineering time. What I found, was that a lot of the bug reports we were getting before, weren't bugs in xterm at all, but were feature requests from people for us to change the default of some option or another, and when we changed that, someone else would file a bug report that it broke something else. Juggling options seems to be a fine art of selecting one desired behaviour for one person, and creating an undesired behaviour for another person. I decided that our goals should be, roughly in order: 1) Make our default out of the box configuration/operation work like the majority of users expect. Assume a PC style keyboard, and that "general case" means "person familiar with how the keyboard works in Microsoft Windows". 2) Keep the defaults for as many things as possible, as close to the upstream sources as possible, to minimize the likelyhood of a Red Hat specific change creating a problem for someone, as that would increase the amount of manpower we might need to dedicate to resolving the problem in what is an "as-is" rpm package. So, while we want to remain as close to upstream as possible, we will still change things from upstream defaults wherever it makes sense to do so to minimize the number of bug reports received. Generally that means making things work like Windows users expect as far as the keyboard workings, but there are a few other changes we need as well. Some of our changes have been removed over time as upstream xterm has changed defaults over time to match, or something else has changed in a way that solves the problem in a different way. ie: the scrollback buffer size change - that wasn't as big as the buffer we used to provide by default, but it was much larger than the previous default, and a fairly good compromise, so we dropped patching for that. I hope this explanation helps to understand some of the resource changes we apply currently. The #1 goal is to receive as close to zero bug reports from people as possible, and when we do receive bug reports, and fixing one of them creates another one, the goal becomes to fix the problem that affects the most people and would thus theoretically generate the most bug reports. That's a fairly sane goal IMHO. ;o) In general, we meet this goal I believe, although the last OS release or so our xterm was missing a few things due to lack of time to spend on it, but it's now back to where it should be I believe, and aside from people prefering different default configuration options, the upstream xterm maintainer Thomas Dickey does a pretty good job at fixing any real "bugs" that people discover. Hope this clarifies things a bit more. Thanks.
Ok. So Debian keyboard guidelines it is. IOW backspace for terminals claiming to be xterm should send ASCII-DEL aka \177. This has the following concequences: - This bug report is valid for both FC3, FC4test2 & rawhide, IOW ncurses(terminfo)'s xterm alias should be patched so that kbs=\177. Please change the status of this bug to assigned, I'll attach a patch shortly. - XTerm needs part of the old app-defaults patches reapplied so that it to sends \177 for backspace instead of ^H . I'll create a patch and a bug report for this. - Parts of a patch I've submitted to konsole (in FC4test2) which amongst other things changes backspace from \177 -> ^H need to be reversed. I'll take care of this.
Created attachment 113282 [details] patch fixing this 'bug" As promised a patch fixing this "bug".
A patch fixing this has been attached, please fix this before FC4test3, aka freeze moment so that this will be fixed in FC4.
Applied, commited & built. Thanks.