https://wiki.archlinux.org/api.php?action=feedcontributions&user=PingFloyd&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:43:49ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Home_and_End_keys_not_working&diff=15013Home and End keys not working2006-09-01T07:44:08Z<p>PingFloyd: </p>
<hr />
<div>[[Category:System Configuration]]<br />
==Why don't my Home and End keys work in terminals?==<br />
<br />
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.<br />
<br />
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.<br />
<br />
The solution seems to be to have the proper setting of the <code>TERM</code> variable. This may take some experimenting by looking in the /usr/share/terminfo/* directories. Each entry is a potential setting of the <code>TERM</code> variable.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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><br />
<br />
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><br />
<br />
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.<br />
<br />
<br />
However, some urxvt (rxvt-unicode) users might still have problems after that. Adding the following to <code>~/.Xdefaults</code> solves the problem<br />
URxvt*keysym.Home: \e[1~<br />
URxvt*keysym.End: \e[4~<br />
<br />
<br />
----<br />
==Getting them to work in less when you're using rxvt as your terminal emulator in X==<br />
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.<br />
$ export TERM=rxvt-color<br />
$ export COLORTERM=rxvt<br />
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>.<br />
<br />
You may want to first check to see what your current environmental variables are for this.<br />
$ printenv | grep TERM<br />
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 above. It 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.<br />
<br />
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>.<br />
$ echo 'export TERM=rxvt' >> ~/.bashrc<br />
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.</div>PingFloydhttps://wiki.archlinux.org/index.php?title=Home_and_End_keys_not_working&diff=15012Home and End keys not working2006-09-01T07:41:43Z<p>PingFloyd: </p>
<hr />
<div>[[Category:System Configuration]]<br />
==Why don't my Home and End keys work in terminals?==<br />
<br />
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.<br />
<br />
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.<br />
<br />
The solution seems to be to have the proper setting of the <code>TERM</code> variable. This may take some experimenting by looking in the /usr/share/terminfo/* directories. Each entry is a potential setting of the <code>TERM</code> variable.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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><br />
<br />
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><br />
<br />
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.<br />
<br />
<br />
However, some urxvt (rxvt-unicode) users might still have problems after that. Adding the following to <code>~/.Xdefaults</code> solves the problem<br />
URxvt*keysym.Home: \e[1~<br />
URxvt*keysym.End: \e[4~<br />
<br />
<br />
----<br />
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.<br />
$ export TERM=rxvt-color<br />
$ export COLORTERM=rxvt<br />
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>.<br />
<br />
You may want to first check to see what your current environmental variables are for this.<br />
$ printenv | grep TERM<br />
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 above. It 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.<br />
<br />
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>.<br />
$ echo 'export TERM=rxvt' >> ~/.bashrc<br />
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.</div>PingFloydhttps://wiki.archlinux.org/index.php?title=Home_and_End_keys_not_working&diff=15011Home and End keys not working2006-09-01T07:09:28Z<p>PingFloyd: </p>
<hr />
<div>[[Category:System Configuration]]<br />
==Why don't my Home and End keys work in terminals?==<br />
<br />
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.<br />
<br />
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.<br />
<br />
The solution seems to be to have the proper setting of the <code>TERM</code> variable. This may take some experimenting by looking in the /usr/share/terminfo/* directories. Each entry is a potential setting of the <code>TERM</code> variable.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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><br />
<br />
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><br />
<br />
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.<br />
<br />
<br />
However, some urxvt (rxvt-unicode) users might still have problems after that. Adding the following to <code>~/.Xdefaults</code> solves the problem<br />
URxvt*keysym.Home: \e[1~<br />
URxvt*keysym.End: \e[4~<br />
<br />
<br />
----<br />
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.<br />
$ export TERM=rxvt-color<br />
$ export COLORTERM=rxvt<br />
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>.<br />
<br />
You may want to first check to see what your current environmental variables are for this.<br />
$ printenv | grep TERM<br />
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.</div>PingFloyd