Strange keyboard when using sqlite shell on linux

I use a linux box connected trough putty. Using it with bash, my keyboard performs well, but when I am using the sqlite shell (sqlite3 program) my keys get crazy:

del=^[[3~
up=^[[A
left=^[[D
right=^[[C
down=^[[B

here is my env (the relevant part):

TERM=linux
SHELL=/bin/bash
SHLVL=1
INPUTRC=/etc/inputrc

I would like to use my keys normally on sqlite, as I do on windows.

my inputrc:

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

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

# Completed names which are symbolic links to
# directories have a slash appended.
set mark-symlinked-directories on

$if mode=emacs

# for linux console and RH/Debian xterm
"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word

# 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
$endif

Solution 1:

(FYI: those are the normal sequences generated by those keys on most terminals, it's up to a terminal or program/library to interpret them. You can show this on a working terminal by pressing Ctrl+v then pressing End or other non-character key, where ctrl-V sets the next keypress to be treated literally.)

Seems like your sqlite3 binary is not using readline, or the readline configuration (inputrc) is broken (less likely if bash is working ok though).

You may be able to confirm/deny if readline is being used with the following, replace which sqlite3 with the full path if it's not in your PATH.

ldd `which sqlite3` 

If you see libreadline.so or similar, then it should work, so check your INPUTRC environment variable, ~/.inputrc and /etc/inputrc. There's a slim chance it's statically linked (libreadline.a), to check try:

strings -a `which sqlite3`| grep -i inputrc

If the strings INPUTRC, ~/.inputrc or /etc/inputrc are present it looks like readline was statically linked, and should work.

(At best you can only get some basic version and compile information (pragma compile_options, if supported) from sqlite3, but not the full set of features, which is why we need to go poking at the binary.)

If neither ldd nor strings indicate readline, then it's almost certain that the binary does not have support.

Otherwise check this answer: SQLite with readline support on Ubuntu

If you don't have readline support in your sqlite3 binary you can wrap it using one of:

rlwrap sqlite3
socat READLINE EXEC:"sqlite3"

Both let you specify a history file on the command line.

You can also check your bash readline bindings, just to make sure that readline is working and configured as expected:

bind -p | egrep '\[[ABCD3].?":'

On my system (running bash-3.x within an rxvt) I get:

"\M-[3~": delete-char
"\M-[D": backward-char
"\M-[C": forward-char
"\M-[B": next-history
"\M-[A": previous-history

\M is "meta", which is equivalent to escape, so where you see "\M-" a "\e" should work too. When printed, escape is represented as ^[ (control-[).