The .inputrc revisited

I've been talking about .inputrc once in a while since a few years:

• Custom JumpStart finish script
• Custom JumpStart finish (extras)
• Shell initialization files 
• Some .inputrc detail 
• Another .inputrc feature 

Now I'm going to revisit it once more and I suspect I'll do it again in the future. But for now the goal is to hopefully provide a better example of more key bindings once a more correct and richer console keyboard configuration is available.

The first notice I would add about BASH key bindings is that it seems to be an exclusively per user configuration (~/.inputrc). That is, it seems that no global /etc/inputrc or /etc/bash/inputrc would work by default, at least under Solaris 11.3 GA. Thus, at first one have no option other than using a per user, local ~/.inputrc.

NOTE

In spite of BASH or READLINE being completely death about processing by default a global /etc/bash/inputrc, I can use an $include /etc/bash/inputrc directive inside an ~/.inputrc as a viable workaround, yet this would not provide partial overriding.

There's no sense in repeating what's explained at BASH(1) so I'll go straight to the example and, if necessary, present a few comments or justifications:

$ cat /etc/bash/inputrc_console_basics
 
$if mode=emacs
# Basic key bindings while under an emacs console terminal. 
# These bindings may be more easily remembered and accessed. 
# This is in spite of bind-tty-special-chars being partially OK.

# OK : forward-char
# OK : backward-char

# Ins
"\e[208z": overwrite-mode

# Del
"\e[214z": delete-char

# Home
"\e[210z": beginning-of-line

# End
"\e[216z": end-of-line

# ^Right
"\e[220z": forward-word

# ^Left
"\e[221z": backward-word

# ^Bksp
"\e[189z": backward-kill-word

# ^Del
"\e[215z": kill-word

# ^Home
"\e[211z": backward-kill-line

# ^End
"\e[217z": kill-line

# ^Down
"\e[222z": downcase-word

# ^Up
"\e[223z": upcase-word

$endif


NOTE

One could consider replacing some or all of the *-word actions above by the corresponding shell-*-word ones, whenever possible. Or perhaps adding a few more actions to the keyboard layout, such as, Shift+Bksp, Shift+Del and so on... in order to gather all the options at the same time, if not too confusing.

The settings below also address the single-user run-state when the terminal gets dumb:

$ cat ~/.inputrc

# To keep sanity.
set bell-style none

# On generic x86-64 this kind of console seems the default.
$if term=sun-color
$include /etc/bash/inputrc_console_basics
$endif

# But while on single-user run-state the terminal gets dumb.
# By default only relates to root but that can be changed with:
# usermod -A +solaris.system.maintenance ...
$if term=dumb
$include /etc/bash/inputrc_console_basics
$endif
 
Why not take the opportunity and also do something to get slightly similar behavior while under an xterm terminal? Even if X isn't installed locally that might be useful while remotely administering from a system that does; typically an SSH session launched from a graphical terminal or yet via some software that emulates an xterm, such as PuTTY. For instance:

$ cat /etc/bash/inputrc_PuTTY_xterm_basics

$if mode=emacs

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

"\e[3~": delete-char
"\e[2~": overwrite-mode

"\eOC": forward-word
"\eOD": backward-word

"\eOA": upcase-word
"\eOB": downcase-word

$endif


NOTE

The escape sequences above are generated by the same key combinations (as available under a default XKB configuration), corresponding to those indicated in comments on the sample input_console_basics above.

Then it would suffice to add an extra inclusion to the above .inputrc sample:

$ cat ~/.inputrc

...

# Trying to mimic some console settings under a PuTTY xterm:
# This assumes an out-of-the-box XKB configuration...
$if term=xterm
$include /etc/bash/inputrc_PuTTY_xterm_basics
$endif
  
NOTE

I'm assuming a basic (out-of-the-box) xterm emulation both from PuTTY or gnome-terminal.  That is, I'm not considering enhanced settings of the TERM enviroment variables such as xterm-256color or putty-256color which would required me to add additional if term= statements to my .inputrc file.

For a gnome-terminal emulated xterm I could have the following differences:

$ cat /etc/bash/inputrc_xterm_basics

$if mode=emacs

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

"\e[3~": delete-char
"\e[2~": overwrite-mode

"\e[1;5C": forward-word
"\e[1;5D": backward-word

"\e[1;5A": upcase-word
"\e[1;5B": downcase-word

$endif
   
NOTE

To find out the proper bindings on each case, once at a certain terminal emulator, I must hit ^V followed by the key combination I wish to detect the associated escape sequence.

  

Keyboard - Layouts

For system administration, specially at a local or serial console, it is important to have a properly configured keyboard layout as in this case it's generally the only input device available to interact with the system. In such cases it would be unfortunate if one would find it out mis-configured under some emergency or critical condition.

This happened to me a few times where I had to interact locally on some special servers and have found that the datacenter where the machines were placed didn't have proper KVM switches but only a few keyboards left over to be physically connected to host in case of emergencies. What was particularly bad is that the keyboards were rather different among brands, versions and languages, so that once plugged in I had to abstract all physical keys markings and work base on the English layout on my mind although a few important keys were frequently missing or mis-configured.

On two older posts I started talking about a way to fix or mitigate this issue:

• Keyboard - Keystations
• Keyboard - Introduction

As an example I'll continue to work on a solution to the following keyboard, which is a Brazilian derivative re-branded by Dell as model KM-632 (BR) from a variant of the original Chicony Electronics model KG-1089:

Keyboard - Keystations

Following my general keyboard introduction which focused on the non-English layout issues of the console I'd like to present on easy / lazy way of detecting the numerical code of each keyboard key according to the Solaris keyboard device driver known as the /dev/kbd.

I call it lazy because it's not based on highly sophisticated techniques or knowledge such as the DDI (device driver interface), STREAMS Unix architecture, dtrace, termio, SMF and so on. A simple shell script will do. The script can be run under a regular non-privileged account but in order to correctly detect the numerical codes of the console keyboard it's necessary to run it directly on the console to avoid interference from other keyboard filtering layers such as X-Windows, Compiz, Gnome and so on.

By the way, regarding the numerical code of a keyboard key, the precise nomenclature adopted by Solaris defines it as a keystation. So the task is to determine the keystations reported by /dev/kbd for each key on your Frankenstein keyboard.

The strategy consists on making each key report its keystation instead of a its current behavior whatever could that be (right or wrong, character or shift or toggle) before the script is run. Once the keystation of each key is know for sure, than it will be possible to fix whatever is necessary to properly configure the keyboard layout.

NOTE

Some keyboards have multimedia keys for volume and playback control as well as some suspend / hibernation keys that aren't reported by /dev/kbd. As the technique I present does not circumvent /dev/kbd, such keys can't be reached by this solution; in other words, unfortunately, they are permanently dead on this context. Not that those keys should necessarily work on a text-mode console, but every available key is a potential additional resource at hand.

Keyboard - Introduction

Upon installing a "modern" system it's mandatory to configure the most basic input and output devices for user interaction with the system, which means at a minimum the keyboard as the main input device and the display as the main output device. Everybody knows that. Many modern systems now have reasonable configuration assistants to properly configure these UI devices and even headless (server) systems provide built-in graphical (web) access which simplifies the basic UI setup for system administration. Yet many systems still count on a (local) console for some off-line maintenance or emergency situations. If you have high-quality hardware that adheres well to standards you may consider yourself lucky and you may disregard this blog post as you shall not have big surprises or issues while attempting to properly configure your UI devices for system administration, specially the keyboard.

But Solaris also runs (reasonably well I should say) on "general" x86 (64-bit) systems and by "general" I mean unqualified / unsupported hardware as well. In such cases, it's very well possible that the first difficulty configuring the system is exactly properly configuring the keyboard as an UI input device for system administration, a.k.a. the console keyboard, an otherwise dumb activity considering the other high-expectations on the overall noble system goals. The main reason for such hurdle in configuring the keyboard console lies on the fact that sometimes non-strictly-standard hardware fail to adhere to the proper / expected layout and behavior. But the blame is not entirely on manufactures, the standardizations staff have failed as well. In some cases, it's possible to perfectly fix things, but not always, as some manufactures perform some hard changes in firmware which are impossible to circumvent through software. I believe that in most cases this issue is driven by cost reduction in contrast to "innovation" or "rationalization" or whatever. The fact is that in the end one may face odd (why not say crazy!) situations. On a following post I hope to present just an example of it alongside to an strategy to fix or minimize the problem.

NOTE

It's true that one seldom revert to the system console as nowadays most can be done remotely from a web UI or a graphical X terminal. A web interface or an X terminal is highly resourceful and configurable, but, again, a system console is another story, specially with non-standard / non-qualified / unsupported hardware. But when disaster strikes and one is forced to run to the system console, a perfectly working keyboard is pure gold.