asigning a certain command to a certain keyboard key
Ahmed
Could any one tell me how to asigning a certain command to a certain keyboard key
for example : instead of typing clear I want to press "F1" key , just as an example.
Stephane CHAZELAS
> Could any one tell me how to asigning a certain command to a certain keyboard key
> for example : instead of typing clear I want to press "F1" key , just as an example.
Which shell, which system, which terminal (xterm, Linux console,
screen within xterm)?
With many shells (tcsh, zsh and all the readline based shells
(bash, rc, es, esh...), hitting <Ctrl-L> clears the screen and
redraws the prompt.
With zsh (4.1)
bindkey $terminfo[kf1] clear-screen
Or if this doesn't work or you have an older version of zsh:
bindkey '\eOP' clear-screen
(change \eOP with the actual characters sent by your shell upon
F1 key press)
If you really want to run a command, you can do:
bindkey -s '\eOP' $'\eqclear\r'
\eq holds the caracters you've typed so far at the prompt so
that they are restored at next prompt, \r is the return key,
"clear" is the command to run.
--
Stéphane ["Stephane.Chazelas" at "free.fr"]
Ahmed
-------------------------------------------------------------------
First thanks alot for your help,
It really worked well but is zsh shell but actually I forgot to tell you
that my default shell is bash under Linux,
so do you know the equivalent of this command in bash shell.
I have also another question if you have time:
You said that \eOP stands for F1 how could I know the remaining of the
keyboard key ?
Thanks alot
Ahmed
----------------------------------------------------------------------
Stephane CHAZELAS
[...]
>> bindkey -s '\eOP' $'\eqclear\r'
> It really worked well but is zsh shell but actually I forgot to tell you
> that my default shell is bash under Linux,
> so do you know the equivalent of this command in bash shell.
No, it's been a long time I dropped bash for zsh. But, if I have
to do it in bash, I'd read its manual and search for "key
binding" or something similar.
> I have also another question if you have time:
> You said that \eOP stands for F1 how could I know the remaining of the
> keyboard key ?
Simply hist <Ctrl-v>, then the key. ^[ is the <Ctrl-[> character
also known as <Esc> whose escape sequence is \e or \033.
If I type <Ctrl-v><End>, here I see ^[[F.
infocmp -1 | grep '\<k'
will also tell you what they are supposed to be in your
terminal.
Unfortunately, it shows the character sequence sent upon key
press when the terminal is in the "application" keypad mode. At
the shell, prompt, it's likely not to be in that mode, it's in
the "normal" keypad mode, in a mode where the <Up> key for
instance sends a character sequence which is actually the escape
sequence that tells the terminal to move the text cursor up, so
the bindkey $terminfo[k...] I was talking about will not work
with every key.
For instance, in xterm, infocmp -L1 gives:
cursor_up=\E[A,
key_up=\EOA,
If I hit <Ctrl-V><Up> at shell prompt, I see ^[[A, but in vi or
after a "tput smkx", I see ^[OA.
Thomas Dickey
> Unfortunately, it shows the character sequence sent upon key
> press when the terminal is in the "application" keypad mode. At
> the shell, prompt, it's likely not to be in that mode, it's in
> the "normal" keypad mode, in a mode where the <Up> key for
> instance sends a character sequence which is actually the escape
> sequence that tells the terminal to move the text cursor up, so
> the bindkey $terminfo[k...] I was talking about will not work
> with every key.
This topic came up in Debian a year or two ago. My suggested solution was
to generate bindings for the normal mode based on the application mode.
In zsh, that turned out to be relatively simple. (I haven't noticed any
comments that indicate bash users have adapted this approach).
> For instance, in xterm, infocmp -L1 gives:
> cursor_up=\E[A,
> key_up=\EOA,
>
> If I hit <Ctrl-V><Up> at shell prompt, I see ^[[A, but in vi or
> after a "tput smkx", I see ^[OA.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
John Green
> This topic came up in Debian a year or two ago. My suggested solution was
> to generate bindings for the normal mode based on the application mode.
> In zsh, that turned out to be relatively simple. (I haven't noticed any
> comments that indicate bash users have adapted this approach).
>
OK, I'll take the bait ;-)
Using bash 2.05b in an xterm under Mandrake Linux 8.2.
As an experiment, I tried to make the F1 key
execute a clear command. The Ctrl-V trick
showed that F1 generates ^[OP
I tried lots of different bind commands, which were accepted without
protest. However, pressing F1 at the command prompt afterwards
just gives this error.
bash_execute_unix_command: cannot find keymap for command
I googled for this message with no helpful results.
Here are some of my attempts to remap the F1 key.
bind -x '"\C-[OP": clear'
bind -x '"\C-[OP":clear'
bind -x '"\C-[OP": /usr/bin/clear'
bind -m emacs -x '"\C-[OP": clear'
bind -m emacs-standard -x '"\C-[OP":clear'
These do *something*, because pressing F1 did not give any
error messages before - it just output 0.
This isn't merely an experiment: some of my laptop's keys
are dead and it would be good to remap function keys instead.
I guess I should edit /etc/inputrc, but I'd really like to
see things work from the command-line first.
Anyone know what I am doing wrong?
PS, I tried bind -v on a linux virtual terminal without X.
The F1 key returns the code ^[[[A, which translates into
bind -x '"\C-[[[A": clear'
The result is the same error message when F1 is
pressed afterwards.
John Green
Stephane CHAZELAS
[...]
> Using bash 2.05b in an xterm under Mandrake Linux 8.2.
>
> As an experiment, I tried to make the F1 key
> execute a clear command. The Ctrl-V trick
> showed that F1 generates ^[OP
>
> I tried lots of different bind commands, which were accepted without
> protest. However, pressing F1 at the command prompt afterwards
> just gives this error.
>
> bash_execute_unix_command: cannot find keymap for command
bash key mapping handling is mostly bogus. You may have more
chance with:
bind -x $'"\201":clear'
bind '"\eOP":'$'"\201"'
Troubles begin as soon as there's one binding for a char
sequence, that gets even worse with "-x".
Stephane CHAZELAS
> Stephane CHAZELAS <this.a...@is.invalid> wrote:
>> Unfortunately, it shows the character sequence sent upon key
>> press when the terminal is in the "application" keypad mode. At
>> the shell, prompt, it's likely not to be in that mode, it's in
>> the "normal" keypad mode, in a mode where the <Up> key for
>> instance sends a character sequence which is actually the escape
>> sequence that tells the terminal to move the text cursor up, so
>> the bindkey $terminfo[k...] I was talking about will not work
>> with every key.
>
> This topic came up in Debian a year or two ago. My suggested solution was
> to generate bindings for the normal mode based on the application mode.
> In zsh, that turned out to be relatively simple. (I haven't noticed any
> comments that indicate bash users have adapted this approach).
I'm not sure to understand what you mean. How would you find out
the normal mode code for "kend" for example from the terminfo
database?
something like:
code=$(tput kend | tr O \[)
?
Would it work with every terminal type?
And for the "home" key in normal mode, is it $(tput home) or
$(tput khome | tr O \[)?
What about krmir wrt smir/rmir?
That's really not clear for me.
Looking at zsh code, for the arrow keys, it gets the termcap
codes for ku, kd, kr, kl. Then maps both \e[A and \eOA to <Up>
if the code returned is either \e[A or \eOA, use hardcoded value
\e[A if the returned value is \e<x> or <x> or "", and use the
returned value otherwise.
John Green
> bash key mapping handling is mostly bogus. You may have more
> chance with:
>
> bind -x $'"\201":clear'
> bind '"\eOP":'$'"\201"'
>
> Troubles begin as soon as there's one binding for a char
> sequence, that gets even worse with "-x".
Thanks, that worked.
Now I need to re-read 'man bash' very carefully
to try to understand why.
John Green
Stephane CHAZELAS
That's just a two step mapping.
First "clear" is mapped to the single character \201 (a
non-valid character in iso-8859-***, so there are few chances
that you may type it on keyboard) in the -x keymap, then <F1> is
mapped to that character.
The bug it works around is not described in the man page. There
are many others regarding key binding. It probably needs to be
reworked totally.
Thomas Dickey
> I'm not sure to understand what you mean. How would you find out
> the normal mode code for "kend" for example from the terminfo
> database?
> something like:
> code=$(tput kend | tr O \[)
yes, something like that. But the example I saw for zsh used builtins
for doing the translation. For example (from /etc/zshrc):
[[ "$terminfo[kcuu1]" == " O"* ]] && bindkey -M viins "${terminfo[kcuu1]/O/[}" vi-up-line-or-history
> Would it work with every terminal type?
no - but probably for all of the ANSI terminals, since the substitution
is following that convention.
> And for the "home" key in normal mode, is it $(tput home) or
> $(tput khome | tr O \[)?
I guess that depends on the particular terminal emulator. The normal vs
application mode for cursor keys is well documented. The other keys follow
according to how the implementor decided to make them consistent (or not).
> What about krmir wrt smir/rmir?
That wouldn't apply - iirc, only some non-ANSI terminals use this.
> That's really not clear for me.
> Looking at zsh code, for the arrow keys, it gets the termcap
> codes for ku, kd, kr, kl. Then maps both \e[A and \eOA to <Up>
> if the code returned is either \e[A or \eOA, use hardcoded value
> \e[A if the returned value is \e<x> or <x> or "", and use the
> returned value otherwise.
Actually the zshrc I'm looking at is a little different. It looks for
(using termcap names) 'up' and 'ku', assumes that if the latter is
missing, the former will do. I guess that assumption is tailored for
termcap's limited 1023-byte size, which means that often the function
keys are omitted.
Zdenek SEKERA
>Stephane CHAZELAS <this.a...@is.invalid> wrote:
>> Unfortunately, it shows the character sequence sent upon key
>> press when the terminal is in the "application" keypad mode. At
>> the shell, prompt, it's likely not to be in that mode, it's in
>> the "normal" keypad mode, in a mode where the <Up> key for
>> instance sends a character sequence which is actually the escape
>> sequence that tells the terminal to move the text cursor up, so
>> the bindkey $terminfo[k...] I was talking about will not work
>> with every key.
>
>This topic came up in Debian a year or two ago. My suggested solution was
>to generate bindings for the normal mode based on the application mode.
>In zsh, that turned out to be relatively simple. (I haven't noticed any
>comments that indicate bash users have adapted this approach).
>
So what was your solution? Would you share the actual code with us?
--
----------------------------------------------------
Zdenek Sekera | zdenek...@cern.ch
LHC Computing Grid Project | tel: +41-22-767.1068
CERN - IT Division | fax: +41-22-767.4900
CH-1211 Geneva 23 |
Switzerland |
----------------------------------------------------
Stephane CHAZELAS
[...]
>>This topic came up in Debian a year or two ago. My suggested solution was
>>to generate bindings for the normal mode based on the application mode.
>>In zsh, that turned out to be relatively simple. (I haven't noticed any
>>comments that indicate bash users have adapted this approach).
>>
>
> So what was your solution? Would you share the actual code with us?
I think that's something like:
typeset -aU k_up k_down k_left k_right
k_up=($terminfo[kcuu1] $terminfo[kcuu1]:s/O/\[/ $terminfo[kcuu1]:s/\[/O/)
k_down=($terminfo[kcud1] $terminfo[kcud1]:s/O/\[/ $terminfo[kcud1]:s/\[/O/)
k_left=($terminfo[kcub1] $terminfo[kcub1]:s/O/\[/ $terminfo[kcub1]:s/\[/O/)
k_right=($terminfo[kcuf1] $terminfo[kcuf1]:s/O/\[/ $terminfo[kcuf1]:s/\[/O/)
for k ($k_up) bindkey $k widget-for-up-key