Klawisz Home działa dziwnie w bash (tty i X) na długich ciągach wejściowych

11

Kiedy uderzę, Homejeśli moje obecne wejście jest wystarczająco krótkie (powiedzmy, <36 znaków), działa dobrze. Jednak gdy wpisałem dłuższe polecenie, a następnie chciałem wrócić do początku, wygląda na to, że wykonuje swoją pracę, ale polecenie nie jest już wyświetlane poprawnie. Wygląda na to, że nie jestem na początku, ale mam około 10 znaków. Chociaż jeśli wpiszę „na ślepo”, to działa dobrze, ale wygląda na totalny bałagan, jakby całe wejście zostało przesunięte w prawo, ale nie przerysowane. Więc piszę na nim, ale „w rzeczywistości” nie, ponieważ miejsce, które „wymazuję”, to „właściwie” 10 znaków po prawej stronie. W związku z tym, jeśli spróbuję skasować polecenie, pierwsze 10 znaków będzie nadal wyświetlanych, ale jeśli Entergo uderzę , wyświetli się kolejny monit, jakby poprzednie wejście było puste.

Wiem, że to nie jest najlepsze wytłumaczenie, ale chodzi o to, że bash rozpoznaje to i próbuje zrobić właściwą rzecz, ale często kończy się niepowodzeniem.

Powielam to zarówno w tty, jak i terminalu w sesji X. Kiedy naciskam Ctrl+, Va potem Homewidzę różne sekwencje ( ^[OHw X, ^[[1~w tty), ale obie wydają się być w moim /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 $TERMpokazuje linuxw xtermsesji tty i X.

Jego

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

Czy ktoś ma na to jakieś wskazówki?

Lew Lewicki
źródło
1
Jak długo jest twój monit? Czy wpisanie wiersza polecenia o długości około 36 znaków wypełnia jeden wiersz terminala, a tym samym powoduje przewijanie strony? Czy nadal występuje, jeśli użyjesz tego monitu? PS1='$ '
Mikel
@Mikel Nie wiem, co masz na myśli, ale najprawdopodobniej jesteś blisko właściwej ścieżki. Wydaje się, że tak się nie dzieje, gdy używam minimalistycznego monitu. Jedna Kiedyś było trochę zmodyfikowany w stosunku do domyślnego: PS1="\e[0;36m[\u@\h \W]\$ \e[m". Czy coś w tym jest nie tak? Wpisanie 36 znaków nie wypełnia jednej linii (jak dotąd). Poza tym nie mam strony przewijanej w tty :)
Lev Levitsky
@Mikel Postępowałem zgodnie z radą jw013 i poprawiłem podpowiedź, która wydaje się rozwiązać. Może mógłbyś wyjaśnić, na czym polegał problem, abym mógł ci wynagrodzić przedstawiciela, który rozwiąże ten problem jako pierwszy :)
Lev Levitsky

Odpowiedzi:

13

Musisz otoczyć niedrukowalne części pytania (w tym między innymi sekwencje specjalne do zmiany kolorów) za pomocą \[i \].

Twoje oryginalne pytanie: \e[0;36m[\u@\h \W]\$ \e[m
Naprawiono pytanie:\[\e[0;36m\][\u@\h \W]\$ \[\e[m\]

\[I \]powiedzieć bash, że wszystko pomiędzy faktycznie nie drukować na ekranie, czyli ma zerową długość. Obliczona długość zachęty jest potrzebna, aby wiedzieć, gdzie echo wpisywanych znaków. Pominięcie \[ \]powoduje bashobliczenie niepoprawnej długości pytania, co często prowadzi do dziwnego zachowania zależnego od geometrii terminala ze względu na bashpomysł, gdzie kursor nie pasuje do rzeczywistości.

jw013
źródło
Dzięki, to rozwiązuje problem. Byłbym wdzięczny za wyjaśnienie: jaki był powód tego zachowania, co robią nawiasy kwadratowe itp. Byłoby miło mieć to wszystko na jednej stronie i mogłoby pomóc komuś innemu w przyszłości.
Lev Levitsky
@LevLevitsky Do odpowiedzi dodałem krótkie wyjaśnienie.
jw013
Wielkie dzięki! To ma dla mnie teraz więcej sensu.
Lev Levitsky