Teclado estranho ao usar o shell sqlite no linux

Question

Eu uso uma caixa de linux conectada através de massa. Usando o bash, meu teclado tem um bom desempenho, mas quando estou usando o shell sqlite (programa sqlite3) minhas teclas ficam loucas:

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

aqui está o meu env (a parte relevante):

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

Eu gostaria de usar minhas chaves normalmente no sqlite, como faço no Windows.

minha entrada:

# 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

    

Answer 1

(FYI: essas são as sequências normais geradas por essas chaves na maioria dos terminais, cabe a um terminal ou programa / biblioteca interpretá-las. Você pode mostrar isso em um terminal de trabalho pressionando Ctrl + v pressionando End ou outra tecla que não seja caractere, onde ctrl-V define o próximo pressionamento de tecla a ser tratado literalmente.

Parece que o seu binário sqlite3 não está usando readline , ou a configuração da linha de leitura ( inputrc ) está quebrada (menos provável se bash estiver funcionando corretamente).

Você pode confirmar / negar se a linha de leitura está sendo usada com o seguinte, substitua which sqlite3 pelo caminho completo, se não estiver em PATH .

ldd 'which sqlite3' 

Se você vir libreadline.so ou similar, então deve funcionar, então verifique sua variável de ambiente INPUTRC , ~/.inputrc e /etc/inputrc . Existe uma chance slim que está estaticamente vinculada ( libreadline.a ), para verificar a tentativa:

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

Se as strings INPUTRC , ~/.inputrc ou /etc/inputrc estiverem presentes, parece que a readline foi estaticamente vinculada e deve funcionar.

(Na melhor das hipóteses você só pode obter alguma versão básica e compilar informações ( pragma compile_options , se suportado) de sqlite3 , mas não o conjunto completo de recursos, e é por isso que precisamos cutucar o binário.)

Se nem ldd nem strings indicar readline, então é quase certo que o binário não tem suporte.

Caso contrário, verifique esta resposta: SQLite com suporte readline no Ubuntu

Se você não tem suporte à linha de leitura no seu sqlite3 binário, você pode encapsulá-lo usando um destes:

rlwrap sqlite3
socat READLINE EXEC:"sqlite3"

Ambos permitem que você especifique um arquivo de histórico na linha de comando.

Você também pode verificar suas ligações de linha de leitura bash , apenas para garantir que a linha de leitura esteja funcionando e configurada como esperado:

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

No meu sistema (executando bash-3.x dentro de um rxvt ) eu recebo:

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

\M é "meta", o que equivale a escape , portanto, onde você vir " \M- " a " \e " também deve funcionar. Quando impresso, escape é representado como ^[ (control- [).