in reply to (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.

Copy and paste to ~/.inputrc. Run bind -f .inputrc to make it active during a session. Does almost most all of what you want....

Details man readline. s/C/\\C/g. English names don't work as advertised. 

# do not bell on tab-completion
set bell-style off

set meta-flag on
set input-meta on
set convert-meta on
set output-meta on


# Alt + Backspace delete by words
# \C-\b does not give you the behaviour you want
# as backspace the key is sent as ^h or ^127 ^\177
# ie it already uses Ctrl+something so Ctrl+Ctrl+something is not vali
+d
"\M-\b": backward-delete-word

# Ctrl + K deletes the current line
"\C-k": kill-whole-line
# Alt + K deletes the current line
"\M-k": kill-whole-line

# for linux console and RH/Debian xterm
# these codes  simulate numeric keypad layout
# found on some old machines when there were less keys

# Home
"\e[1~": beginning-of-line

# End
"\e[4~": end-of-line

# Page Up
"\e[5~": beginning-of-history

# Page Down
"\e[6~": end-of-history

# this makes DEL key a universal deleter
# it deletes under the cursor if there is a char there
# at ^ it deletes like a normal delete key
# at $ it deletes like a backspace key
"\e[3~": forward-backward-delete-char


# these control how the arrows work
# arrow keys are problematic due to erratic placement
# net effect of this is that arrows work as normal
# but alt arrow or control arrow moves by word

# this is control arrow
"\eOC": forward-word
"\eOD": backward-word

# this is alt arrow
"\e\e[C": forward-word
"\e\e[D": backward-word

# misc miscompatibility hacks!

# for rxvt
"\e[8~": end-of-line

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
"\eOH": beginning-of-line
"\eOF": end-of-line

# for freebsd console
"\e[H": beginning-of-line
"\e[F": end-of-line

[download]

To find out what your clients keymappings *really* are just run this script: 

[root@devel3 root]# cat key
#!/usr/bin/perl
use Term::ReadKey;
my $RAW = $ARGV[0] ? 1 : 0;
ReadMode 4 unless $RAW;
sleep 1 while (not defined ($key = ReadKey(-1)))
printf "Get key '%s' %d \%o\n", $key, ord($key), ord($key);
ReadMode 0 unless $RAW;
[root@devel3 root]#

[download]

It is very handy. Just press the key (combo) and read the result. Called with the raw arg (actually any true value) it will show you the key mappings in ANSI style. You need to do this as lots of special keyboard keys are ASCII 7. Anyway without it it will give you the key and dec and octal names which may or may not help. Note in raw mode when you see a key combo produce: 


^[

this must be replaced with:

\e

in the .inputrc file. So if you run ./key and say press Ctrl+Left_Arro
+w you will get this:

$ ./key raw
^[OC

Anyway now we know Ctrl+Left_Arrow is ^[OC 
so in your .inputrc you put:

"\eOC": forward-word

note s/\^[/\\e/g   Then do a bind -f .inputrc and it just works.

[download]

cheers

tachyon

Replies are listed 'Best First'.
Re: Re: (OT): .inputrc mapping PC keyboard to sensible set vi or set emacs functions.
by BrowserUk (Patriarch) on Mar 03, 2004 at 02:02 UTC

    I've followed these instructions to the letter, and still nothing works.

    Whether I use a vanilla putty session, (I blew it away and re-installed from scratch to ensure that nothing was left over from my earlier attempts to configure). Or a vanilla SSH 3.2.9 (build 283) (Also re-installed from scratch).

    In both cases, with the .inputrc file from above, uploaded using the SSH file transfer widget and bound using the command shown. Nothing works.

    I also tried logging out and logging back in, in the forelorn hope that the .inputrc file would be read and acted upon when a new session was started, but still nothing changed. I think that the problem lies in the set up at the host end rather than PC end. Maybe it is non-standard. Surely not everyone using a (RH 7) linux system has to go through this?

    None of the edit keys do anything at all except the backspace key? I cannot even retrieve the previous command using the up-arrow.

    All of which has made my use of Linux over the last 6-weeks a less than wow experience.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
[reply]
      Maybe your SSH client is junk. What happens when you SSH from a similar linux system to another? PuTTY works well for when I need to use a Windows client (which is not often -- but PuTTY is decent).

      Also, which Linux distribution (name and version) is this?

[reply]

        Thanks, but I have tried no less that 7 different shells: Putty, SSH 3.2.9, Secure Koala Term, Tera Term, AniTa and a couple of others that I failed to keep track off.

        All have some advantages and disadvantages.

        • Putty

          I can't find a way to resume the current session when my isp drops the ball.

        • SSH 3.2.9

          This better in some senses in that it remembers what host and userid you were using and only requires you to hit the spacebar and retype the password, but it has other constraints. It only seems to do one sort of terminal emulation, and that emulation doesn't have any way of distinguishing between cursor-left and control-cursor-left etc.

        • AniTa

          Very powerful. Emulates almost anything you could want, has fully configurable keyboard mappings, scripting language and a lot more besides. Unfortunately, it also comes with a load of 3d-whizzy baggage that gets in the way, and spreads it's configuration across about a dozen files and dialogs in a way that is almost incomprehensible. I simply gave up trying to work out how to set it up.

        • Secure Koala Term is pretty neat. Unfortunately it tries so hard to emulate a limited set of Dec terminals that were old hat when I started programmng and haven't been manufactured since before many of the people reading this were born, that it is severly limiting. If your an afficinado of Dec's EDT editor it would be great, but the last time I used that was 1984.
        • Tera Term

          I forgot why I threw this one out. Needless to say, I wasn't too impressed.

        The main problem I was having was more to do with finding out what functions where available (bind -p), and what they did, which isn't entirely obvious from their names.

        Then what character sequences were generated by what keys, and that depends on which terminal your emulator emulates.

        Finally, somewhere in one of my attempts to configure the keyboard to what I consider to be a rational set of mappings, I obviously deleted something vital because I arrived at a point where simply nothing worked.

        My hope was that someone with a good understand of the interactions between emulator types/ vi -v- emacs modes, bind, .inputrc, readline and all the other bits and pieces that go together to cause pressing a key on my keyboard to do something on the host had already done the work.

        The BOFH that manages the system in question has managed to restore the status quo and enhance it somewhat closer to my idea of a sensible configuration. The mappings only seem to work with Putty -- not SSH or any of the others for reasons that completely elude me, but it's better than where I was a few days ago:)

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
[reply]
[d/l]

In Section Seekers of Perl Wisdom