Uzun giriş dizelerinde bash (tty ve X) garip davranan ev anahtarı

HomeMevcut girişim yeterince kısaysa (diyelim <36 karakter) vurduğumda iyi çalışıyor. Ancak, daha uzun bir komut yazıp daha sonra başa dönmek istediğimde, işini yapıyor gibi görünüyor, ancak komut artık görüntülenmiyor . Sanki başlangıçta değilim, yaklaşık 10 karakterim varmış gibi görünüyor. "Körü körüne" yazarsam iyi çalışır, ancak tam bir karmaşaya benziyor, sanki tüm girdi sağa kaymış, ancak yeniden çizilmemiş gibi. Bu yüzden üzerine yazıyorum, ama "aslında" değil, çünkü "sildiğim" yer "aslında" 10 karakter sağda. Buna göre, komutu silmeye çalışırsam, ilk 10 karakter hala görüntülenir, ancak Entervurursam önceki giriş boşmuş gibi başka bir istem görüntüler.

Bunun şimdiye kadarki en iyi açıklama olmadığını biliyorum, ama mesele şu ki, bash onu tanır ve doğru olanı yapmaya çalışır, ancak çoğu zaman başarısız olur.

Bunu X oturumunda hem tty'de hem de terminalde yeniden üretiyorum. Ben vurduğunda Ctrl+ Vve sonra Homeben (farklı dizileri görmek ^[OH, X ^[[1~tty), ancak her ikisi de benim, görünmektedir /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 $TERMgösterileri linuxtty'den ve xtermX oturumunda.

Onun

GNU bash, sürüm 4.2.24 (2) -çalışma (i686-pc-linux-gnu)

Bunun hakkında ipucu olan var mı?

bash command-line arch-linux

— Lev Levitsky
kaynak

İsteminiz ne kadar sürüyor? Yaklaşık 36 karakter uzunluğunda bir komut satırı yazmak terminalinizin bir satırını dolduruyor mu ve bu nedenle yan kaydırmaya neden oluyor mu? Bu istemi kullanırsanız hala oluyor mu? PS1='$ '

— Mikel

@Mikel Aklından geçenleri bilmiyorum, ama büyük olasılıkla doğru yola yakınsın. Minimalist istemi kullandığımda bu görünmüyor. Kullandığım bir varsayılan bir kıyasla modifiye biraz: PS1="\e[0;36m[\u@\h \W]\$ \e[m". Bunda yanlış olan bir şey var mı? 36 karakter yazmak bir satırı doldurmaz (açık ara). Ayrıca, tty içinde yan kaydırma yok :)

— Lev Levitsky

@Mikel jw013'ün tavsiyelerini izledim ve çözdüğü anlaşılan istemi ayarladım. Belki de sorunun ne olduğunu açıklayabilirsin, böylece seni ilk önce

— anlayacak

İsteminizin yazdırılmayan bölümlerini (renkleri değiştirmek için kaçış dizileri dahil ancak bunlarla sınırlı olmamak üzere) \[ve ile çevrelemeniz gerekir \].

Orijinal isteminiz: \e[0;36m[\u@\h \W]\$ \e[m
Sabit istem:\[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

\[Ve \]anlatmak bashaslında ekrana yazdırmıyor aradaki her şeyin, yani sıfır uzunluğa sahiptir. Yazdığınız karakterlerin nerede yankılanacağını bilmek için hesaplanan bilgi istemi uzunluğu gerekir. Ayrılmak yanlış bir istem uzunluğunun hesaplanmasına \[ \]neden olur bash, bu bashda imlecin gerçekle eşleşmediği fikri nedeniyle genellikle garip terminal geometrisine bağımlı davranışlara yol açar .

— jw013
kaynak

Teşekkürler, bu sorunu çözdü. Yine de bazı açıklamaları takdir ediyorum: bu davranışın nedeni neydi, köşeli parantezler ne yapar, vb. Hepsini bir sayfada bulundurmak ve gelecekte başka birine yardımcı olmak güzel olurdu.

— Lev Levitsky

@LevLevitsky Cevaba kısa bir açıklama ekledim.

— jw013

Çok teşekkürler! Bu benim için şimdi daha anlamlı.

— Lev Levitsky