Tombol home bertingkah aneh di bash (tty dan X) pada string input panjang

11

Ketika saya menekan Homejika input saya saat ini cukup pendek (katakanlah, <36 karakter), itu berfungsi dengan baik. Namun, ketika saya mengetikkan perintah yang lebih panjang dan kemudian ingin kembali ke awal, sepertinya ia melakukan tugasnya, tetapi perintah itu tidak ditampilkan lagi. Sepertinya saya bukan di awal tetapi sekitar 10 karakter. Meskipun jika saya mengetik "secara membabi buta", itu berfungsi dengan baik, tetapi sepertinya berantakan total, seolah-olah seluruh input digeser ke kanan, tetapi tidak digambar ulang. Jadi saya mengetik di atasnya, tetapi "sebenarnya" tidak, karena tempat saya "menghapus" adalah "sebenarnya" 10 karakter di sebelah kanan. Dengan demikian, jika saya mencoba untuk menghapus perintah, 10 karakter pertama masih ditampilkan, tetapi jika saya tekan Enteritu hanya menampilkan prompt lain seolah-olah input sebelumnya kosong.

Saya tahu ini bukan penjelasan terbaik yang pernah ada, tetapi intinya adalah bahwa bash mengenalinya dan mencoba melakukan hal yang benar, tetapi sering gagal.

Saya mereproduksi ini dalam tty dan di terminal dalam sesi X. Ketika saya menekan Ctrl+ Vdan kemudian Homesaya melihat urutan yang berbeda ( ^[OHdalam X, ^[[1~dalam tty), tetapi keduanya tampaknya di /etc/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

$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[7~": beginning-of-line
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": 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

echo $TERMditampilkan linuxdalam xtermsesi tty dan X.

Nya

GNU bash, versi 4.2.24 (2) -release (i686-pc-linux-gnu)

Adakah yang punya petunjuk tentang ini?

Lev Levitsky
sumber
1
Berapa lama prompt Anda? Apakah mengetikkan baris perintah sepanjang 36 karakter mengisi satu baris terminal Anda, dan dengan demikian menyebabkan pengguliran samping? Apakah itu masih terjadi jika Anda menggunakan prompt ini? PS1='$ '
Mikel
@Mikel Saya tidak tahu apa yang ada dalam pikiran Anda, tetapi Anda kemungkinan besar berada di dekat jalur yang benar. Sepertinya tidak terjadi ketika saya menggunakan prompt minimalis. Yang saya digunakan adalah sedikit dimodifikasi dibandingkan dengan default: PS1="\e[0;36m[\u@\h \W]\$ \e[m". Apakah ada yang salah dengan itu? Mengetik 36 karakter tidak mengisi satu baris (sejauh ini). Juga, saya tidak punya sisi bergulir di tty :)
Lev Levitsky
@Mikel saya mengikuti saran jw013 dan menyesuaikan prompt, yang sepertinya menyelesaikannya. Mungkin Anda bisa menguraikan apa masalahnya sehingga saya bisa memberi Anda imbalan sebagai orang yang akan mengetahuinya terlebih dahulu :)
Lev Levitsky

Jawaban:

13

Anda harus mengelilingi bagian non-cetak dari prompt Anda (termasuk tetapi tidak terbatas untuk keluar dari urutan perubahan warna) dengan \[dan \].

Prompt orisinal Anda: \e[0;36m[\u@\h \W]\$ \e[m
Prompt tetap:\[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

The \[dan \]memberitahu bashbahwa segala sesuatu di antara tidak benar-benar mencetak ke layar, yaitu memiliki panjang nol. Panjang prompt yang dihitung diperlukan untuk mengetahui di mana gema karakter yang Anda ketikkan. Meninggalkan \[ \]penyebab bashuntuk menghitung panjang prompt yang salah, yang sering mengarah ke perilaku terminal-dependen aneh geometri karena bashgagasan di mana kursor tidak cocok dengan kenyataan.

jw013
sumber
Terima kasih, ini menyelesaikan masalah. Saya menghargai beberapa penjelasan: apa alasan perilaku itu, apa yang dilakukan tanda kurung siku, dll. Akan menyenangkan untuk memiliki semuanya pada satu halaman dan dapat membantu orang lain di masa depan.
Lev Levitsky
@LevLevitsky Saya menambahkan penjelasan singkat pada jawabannya.
jw013
Terima kasih banyak! Itu lebih masuk akal bagi saya sekarang.
Lev Levitsky