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

From ArchWiki
Jump to: navigation, search
(flag accuracy)
(48 intermediate revisions by 19 users not shown)
Line 1: Line 1:
[[Category:System Configuration]]
+
{{accuracy|reason=Escape codes should not be hardcoded as is done on this page. These escape codes vary in meaning per terminal, which is why terminfo exists in the first place. In zsh you can use the {{ic|$terminfo}} associative array, and in other shells you can use {{ic|tput}}.}}
==Why don't my Home and End keys work in terminals?==
+
[[Category:Command shells]]
 +
[[Category:Keyboards]]
 +
{{Note|This page previously contained some bad advice.  Setting the TERM environment variable in your ~/.bashrc is a '''BAD''' idea.  Please do not do it.  Follow the advice below.}}
  
A: This is a common problem that seems to have multiple causes.  There may be issues with the readline library, but it seems that the default <code>/etc/inputrc</code> fixes these, at least in emacs mode.
+
==Why do not my Home and End keys work in terminals?==
  
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.
+
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).
  
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.
+
Typically, command line applications use ''libreadline'' for interactionIf you know it does not use readline, this tactic may or may not work. For instance, ncurses applications most likely do not use libreadline, BUT ncurses is usually smart enough to map your Home/End keys properly.
  
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.
+
===libreadline problem===
  
However, setting <code>TERM=xterm-xfree86</code> seems to solve the problemIf 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.
+
Usually applications are able to fix this on their ownThe '''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.
  
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.
+
'''Do not set $TERM manually.  Let the terminal do it.'''
  
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>
+
When in bash, do the following:
 +
echo $TERM
  
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>
+
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.
  
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.
+
For xterm and urxvt, it is in <code>~/.Xresources</code>
 +
XTerm*termName: xterm-256color
 +
...
 +
  URxvt*termName: rxvt-unicode
  
 +
For screen, you can set the $TERM variable in your ~/.screenrc with:
 +
term screen-256color
  
However, some urxvt (rxvt-unicode) users might still have problems after that. Adding the following to <code>~/.Xdefaults</code> solves the problem
+
''TODO add more terminal configurations here''
URxvt*keysym.Home:          \e[1~
+
URxvt*keysym.End:          \e[4~
+
  
 +
===I do not touch my TERM value, and the keys still do not work right===
  
----
+
This can happen.  Not everything is covered 100% of the timeBut libreadline had a workaround for this.
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.
+
libreadline maintains mappings for more obscure keys in /etc/inputrc (or ~/.inputrc for user-by-user changes).
$ 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 look at the Arch /etc/inputrc, you will see the following lines:
  $ printenv | grep TERM
+
"\e[1~": beginning-of-line
If that doesn't work then you may want to use <code>lesskey</code> to create set the key bindings for you. This was another step that I had done prior to all of the above.  It may not have been necessary and did not seem to get the keys working.
+
"\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).
 +
 
 +
===Adjusting terminfo (If nothing helps)===
 +
* Do <pre>infocmp $TERM &gt;terminfo.src</pre>
 +
* Edit terminfo.src file in current directory to adjust keystrings. For example change khome and kend.
 +
<pre>khome=\E[1~, kend=\E[4~, </pre>
 +
{{Warning|1=Please check that no other key use the same character sequence.}}
 +
* Run <pre>tic terminfo.src</pre> This command creates ~/.terminfo directory
 +
* Add <pre>export TERMINFO=~/.terminfo</pre> to your profile
 +
{{Tip|1=Of course this works only for termcap/terminfo capable programs. Other ones should have own keymap configuration mechanism}}
 +
 
 +
==Why do not 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 wideYour 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
 +
 
 +
===URxvt/Rxvt===
 +
 
 +
In your X resources (in ~/.Xresources file) you should add something like following:
 +
 
 +
<pre>
 +
URxvt*keysym.Home: \033[1~
 +
URxvt*keysym.End: \033[4~
 +
</pre>
 +
 
 +
===Zsh===
 +
 
 +
See [[Zsh#Key_Bindings]].
 +
 
 +
===Less===
 +
Create file ~/.less with
 +
 
 +
<pre>
 +
$ lesskey -o .less -
 +
#command
 +
\e[4~ goto-end
 +
\e[1~ goto-line
 +
</pre>
 +
 
 +
or for making less work in xterm
 +
 
 +
<pre>
 +
$ lesskey -o .less -
 +
#command
 +
\eOF goto-end
 +
\eOH goto-line
 +
</pre>
 +
 
 +
or you may create systemwide config the same way.

Revision as of 17:46, 9 November 2012

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Escape codes should not be hardcoded as is done on this page. These escape codes vary in meaning per terminal, which is why terminfo exists in the first place. In zsh you can use the $terminfo associative array, and in other shells you can use tput. (Discuss in Talk:Home and End keys not working#)
Note: This page previously contained some bad advice. Setting the TERM environment variable in your ~/.bashrc is a BAD idea. Please do not do it. Follow the advice below.

Why do not 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 do not use libreadline, BUT ncurses is usually smart enough to map your Home/End keys properly.

libreadline problem

Usually applications are able to fix 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 $TERM 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 ~/.Xresources

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

For screen, you can set the $TERM variable in your ~/.screenrc with:

term screen-256color

TODO add more terminal configurations here

I do not touch my TERM value, and the keys still do not work right

This can happen. Not everything is covered 100% of the 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).

Adjusting terminfo (If nothing helps)

  • Do
    infocmp $TERM >terminfo.src
  • Edit terminfo.src file in current directory to adjust keystrings. For example change khome and kend.
khome=\E[1~, kend=\E[4~, 
Warning: Please check that no other key use the same character sequence.
  • Run
    tic terminfo.src
    This command creates ~/.terminfo directory
  • Add
    export TERMINFO=~/.terminfo
    to your profile
Tip: Of course this works only for termcap/terminfo capable programs. Other ones should have own keymap configuration mechanism

Why do not 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

URxvt/Rxvt

In your X resources (in ~/.Xresources file) you should add something like following:

URxvt*keysym.Home: \033[1~
URxvt*keysym.End: \033[4~

Zsh

See Zsh#Key_Bindings.

Less

Create file ~/.less with

$ lesskey -o .less -
#command
\e[4~ goto-end
\e[1~ goto-line

or for making less work in xterm

$ lesskey -o .less -
#command
\eOF goto-end
\eOH goto-line

or you may create systemwide config the same way.