Difference between revisions of "Home and End keys not working"

From ArchWiki
Jump to: navigation, search
Line 1: Line 1:
 
[[Category:Customizing (English)]]
 
[[Category:Customizing (English)]]
 
[[Category:HOWTOs (English)]]
 
[[Category:HOWTOs (English)]]
 +
 +
→ ''This page previously contained some bad advice.  Setting the TERM environment variable in your ~/.bashrc is a '''BAD''' idea.  Please don't do it.  Follow the advice below''
 +
 
==Why don't my Home and End keys work in terminals?==
 
==Why don't my Home and End keys work in terminals?==
  
A: This is a common problem that seems to have multiple causesThere may be issues with the readline library, but it seems that the default <code>/etc/inputrc</code> fixes these, at least in emacs mode.
+
Technically, this is a little wrongYour home and end keys work fine in a terminal.  They ''don't'' work, however, in your shell (bash).
 +
 
 +
Typically, command line applications use ''libreadline'' for interaction.  If you know it does not use readline, this tactic may or may not work.  For instance, ncurses applications most likely don't use libreadline, BUT ncurses is usually smart enough to map your Home/End keys properly.
 +
 
 +
===Ok, great, this is a libreadline problem, how does that help me fix it?===
 +
 
 +
Well, usually, applications are able to do this on their own.  The '''number one cause of this problem''' is setting your TERM variable to something it is not in bashrc.  All modern terminals are smart enough to set their own term variable.  Do not set it manually.  Let the terminal do it.
  
The problem still seems to exist with ncurses based applications including less, nano, and centericq (to name but a few). These do not appear to use the readline library, or do not use the inputrc mappings.
+
When in bash, do the following:
 +
echo $TERM
  
The solution seems to be to have the proper setting of the <code>TERM</code> variableThis may take some experimenting by looking in the /usr/share/terminfo/* directories. Each entry is a potential setting of the <code>TERM</code> variable.
+
You may or may not like the value it sets (i.e. 'xterm' when you want 'xterm-256color')That is fine. Typically there is a way to configure your terminal to change this without changing the TERM variable.
  
In xterm setting <code>TERM=xterm-color</code> DOES NOT solve the Home/End issues. This is often the default <code>TERM</code> setting people recommend.
+
For xterm and urxvt, it is in <code>~/.Xdefaults</code>
 +
XTerm*termName: xterm-256color
 +
...
 +
URxvt*termName: urxvt-unicode
  
However, setting <code>TERM=xterm-xfree86</code> seems to solve the problem.  If you use the linux console instead of a terminal emulator, setting <code>TERM=linux</code> seems to solve the problem. You can do this each time you start a terminal, or export it in your <code>~/.bashrc</code> file.
+
''TODO add more terminal configurations here''
  
Other terminals, including konsole, and rxvt have several entries in the terminfo database that you may need to experiment with. If you find a suitable <code>TERM</code> setting for your favourite terminal, please enter it into this wiki file.
+
===I don't touch my TERM value, and the keys still don't work right===
  
If you use a resource-based terminal such as xterm, rxvt, and aterm, another (better) way of solving the problem is to add <code>xterm*termName: xterm-xfree86</code> to your <code>~/.Xdefaults</code>, and to add <code>xrdb ~/.Xdefaults</code> to your <code>~/.xinitrc</code>
+
This can happen.  Not everything is covered 100% of them time. But libreadline had a workaround for this.
 +
libreadline maintains mappings for more obscure keys in /etc/inputrc (or ~/.inputrc for user-by-user changes).
  
If you use KDE's Konsole, you can open the <code>Settings -> Configure Konsole</code> menu item, click the <code>Session</code> tab, select <code>Shell</code> from the <code>Session</code> list, and change the value of the <code>$TERM</code> textfield to <code>xterm-xfree86</code>
+
If you look at the Arch /etc/inputrc, you will see the following lines:
 +
"\e[1~": beginning-of-line
 +
"\e[4~": end-of-line
 +
"\e[7~": beginning-of-line
 +
"\e[8~": end-of-line
 +
"\eOH": beginning-of-line
 +
"\eOF": end-of-line
 +
"\e[H": beginning-of-line
 +
"\e[F": end-of-line
  
Xorg users can try to set the <code>$TERM</code> value to <code>xterm-xf86-v40</code>This one fix the home/end keys and prevent display corruption on nano and maybe other apps.
+
All of these try to map your Home/End key values.  To see the actual value of yours, you can use yet another libreadline binding, called "quoted-insert" which outputs the actual value of a key, rather than issuing the keypressquoted-insert is typically "Ctrl-v".
 +
Let's try an example (done on urxvt):
 +
Ctrl-v F6 outputs ^[[17~
 +
Ctrl-v Ctrl-c outputs ^C
 +
Ctrl-v Home outputs ^[[1~
 +
Ctrl-v End outputs ^[[4~
  
 +
For future reference, the ^[ is a literal (quoted-insert) Esc keypress.  This means that these keys are actually sending "ESC [ 4 ~".  In inputrc syntax, the ESC key is expressed with "\e" (as you can see above).
  
However, some urxvt (rxvt-unicode) users might still have problems after that. Adding the following to <code>~/.Xdefaults</code> solves the problem
+
For example the urxvt keys shown above would be:
  URxvt*keysym.Home:          \\e[1~
+
  "\e[1~": beginning-of-line
  URxvt*keysym.End:          \\e[4~
+
  "\e[4~": end-of-line
  
 +
If your Home and End key values are not listed in /etc/inputrc (as you can see, with the ^[ to \e conversion, mine ARE listed), you need to add them there.  99% of the time this will not effect other terminals.  Technically, one should add these settings to ~/.inputrc, because it's easier to keep track of, and stays with your user that way.  You can also do '''MUCH''' cooler things with a user-specific inputrc (See [[Inputrc]] for more details).
  
----
+
==Why don't my Home and End keys work in application XYZ?==
==Getting them to work in less when you're using rxvt as your terminal emulator in X==
+
In order to get the <code>HOME</code> and <code>END</code> keys work properly in <code>less</code> when using <code>rxvt</code>, The <code>TERM</code> environmental variable must be set to <code>rxvt</code>.  You can test this on the fly by typing.
+
$ export TERM=rxvt-color
+
$ export COLORTERM=rxvt
+
The above is what worked in my particular situation.  I originally had the <code>COLORTERM</code> environmental variable set to <code>rxvt</code>.  I believe it is set that way by installation of rxvt through pacman by default.  So it may not be necessary to set that.  It may even be superfluous.  I'm am not sure.  So I would recommend that you expirement to see if it's truly necessary.  For me, what got the keys working right was the changing of <code>TERM</code>.
+
  
You may want to first check to see what your current environmental variables are for this.
+
If you've gone through the above, and your TERM is set properly, and your Home and End keys are properly entered into /etc/inputrc and ~/.inputrc, this is no longer system wideYour keys are correct, but the application is notYou will have to consult the documentation for the given app on how to do this.  Hopefully we can add some examples here as we come across broken applications.
  $ printenv | grep TERM
+
If that doesn't work then you may want to try using <code>lesskey</code> to instruct <code>less</code> how handle the keys (in theory shouldn't be necessary since less uses these keys by default, unless of course, you want them binded to something other than their default actions).  This was another step that I had done prior to all of the aboveIt may not have been necessary and did not seem to get the keys working until the <code>TERM</code> environmental variable was set how I outlined here.
+
  
If this ends up working for you and you decide you want to make it permanent, so that whenever you open up <code>rxvt</code>, then it must be added to an appropriate bash init script.  One example of this is by adding it to your <code>~/.bashrc</code>.
+
===Lynx===
$ echo 'export TERM=rxvt' >> ~/.bashrc
+
In lynx.cfg, use the quoted-insert characters above, replacing ^[ with \033:
This should append it to the file. Another way is to open up the file with your favorite editor and edit manually (safer method that prevents possible clobbering from a typo etc.).  This example is user specific and will set that variable whenever you open up an <code>rxvt</code> terminal in X.  Some may prefer to have it act more globally so, that as new users are added, it will be in effect for them as well.  reference the bash man page for details of how to do that.  However, doing so may prove to be cumbersome in cases where you use more than one type of terminal emulator program in X. This is unknown to me since I use rxvt almost exclusively. However, if you're using different terminal emulators in X, placing the above lines in your .bashrc file may not be ideal either depending upon what the other terminals in question need for their environmental variables.  So it may be desirable to expirement with all of your consoles and terminals before making it permanent so that they all still exhibit the desired behavior and that this change isn't the cause of grief down road after you have forgotten that you changed one of your bash init scripts.
+
  setkey "\033[1~" HOME
 +
  setkey "\033[4~" END

Revision as of 05:15, 4 March 2007


This page previously contained some bad advice. Setting the TERM environment variable in your ~/.bashrc is a BAD idea. Please don't do it. Follow the advice below

Why don't my Home and End keys work in terminals?

Technically, this is a little wrong. Your home and end keys work fine in a terminal. They don't work, however, in your shell (bash).

Typically, command line applications use libreadline for interaction. If you know it does not use readline, this tactic may or may not work. For instance, ncurses applications most likely don't use libreadline, BUT ncurses is usually smart enough to map your Home/End keys properly.

Ok, great, this is a libreadline problem, how does that help me fix it?

Well, usually, applications are able to do this on their own. The number one cause of this problem is setting your TERM variable to something it is not in bashrc. All modern terminals are smart enough to set their own term variable. Do not set it manually. Let the terminal do it.

When in bash, do the following:

echo $TERM

You may or may not like the value it sets (i.e. 'xterm' when you want 'xterm-256color'). That is fine. Typically there is a way to configure your terminal to change this without changing the TERM variable.

For xterm and urxvt, it is in ~/.Xdefaults

XTerm*termName: xterm-256color
...
URxvt*termName: urxvt-unicode

TODO add more terminal configurations here

I don't touch my TERM value, and the keys still don't work right

This can happen. Not everything is covered 100% of them time. But libreadline had a workaround for this. libreadline maintains mappings for more obscure keys in /etc/inputrc (or ~/.inputrc for user-by-user changes).

If you look at the Arch /etc/inputrc, you will see the following lines:

"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[7~": beginning-of-line
"\e[8~": end-of-line
"\eOH": beginning-of-line
"\eOF": end-of-line
"\e[H": beginning-of-line
"\e[F": end-of-line

All of these try to map your Home/End key values. To see the actual value of yours, you can use yet another libreadline binding, called "quoted-insert" which outputs the actual value of a key, rather than issuing the keypress. quoted-insert is typically "Ctrl-v". Let's try an example (done on urxvt):

Ctrl-v F6 outputs ^[[17~
Ctrl-v Ctrl-c outputs ^C
Ctrl-v Home outputs ^[[1~
Ctrl-v End outputs ^[[4~

For future reference, the ^[ is a literal (quoted-insert) Esc keypress. This means that these keys are actually sending "ESC [ 4 ~". In inputrc syntax, the ESC key is expressed with "\e" (as you can see above).

For example the urxvt keys shown above would be:

"\e[1~": beginning-of-line
"\e[4~": end-of-line

If your Home and End key values are not listed in /etc/inputrc (as you can see, with the ^[ to \e conversion, mine ARE listed), you need to add them there. 99% of the time this will not effect other terminals. Technically, one should add these settings to ~/.inputrc, because it's easier to keep track of, and stays with your user that way. You can also do MUCH cooler things with a user-specific inputrc (See Inputrc for more details).

Why don't my Home and End keys work in application XYZ?

If you've gone through the above, and your TERM is set properly, and your Home and End keys are properly entered into /etc/inputrc and ~/.inputrc, this is no longer system wide. Your keys are correct, but the application is not. You will have to consult the documentation for the given app on how to do this. Hopefully we can add some examples here as we come across broken applications.

Lynx

In lynx.cfg, use the quoted-insert characters above, replacing ^[ with \033:

setkey "\033[1~" HOME
setkey "\033[4~" END