Dlaczego CTRL-r działa dziwnie (pokazuje tylko część polecenia) w OS X

Ctrl+ rto świetne małe narzędzie do wyszukiwania .bash_historywcześniej uruchomionych poleceń.

Jednak gdy używam go w moim OS X Terminal.app, widzę dziwne zachowanie i zastanawiałem się, czy ktoś inny widzi to samo lub wie, jak to naprawić.

1. Ctrl+r
2. wpisz coś takiego find
3. och spoko, patrz ... to polecenie, które chciałem find . -exec grep -q "hello world" '{}' \; -print
4. Chcę uruchomić to polecenie, ale zmień Witaj świecie na coś innego.
5. Więc uderzyłem ←lub→
6. Teraz polecenie to SORTA w wierszu polecenia, ale zawsze wygląda jak jakaś uproszczona wersja polecenia, taka jak ta: -q "blog_posts_by" '{}' \; -printgdzie jest całe polecenie i mogę używać klawiszy kursora do poruszania się po linii, ale nie wszystkie jest drukowane. Istnieje rozdźwięk między tym, co jest wyświetlane na linii, a tym, co terminal myśli, że edytuję.

Czy ktoś ma pojęcie, dlaczego tak się dzieje? Przeszukiwanie sieci nie jest łatwym zjawiskiem.

Prawdopodobnie masz sekwencje specjalne dla kolorów w pytaniu, które nie są odpowiednio rozdzielane. Muszą być zamknięte w \[i \].

PS1='\[\033[1;36m\]\u\[\033[0m\]@\[\033[1;34m\]\h\[\033[0m\]\$ `

Długość nie drukowanych sekwencji znaków nie jest uwzględniana w długości monitu, gdy są one w ten sposób ujęte, a pozycja poprzednich poleceń musi zostać obliczona dla poprawnego wyświetlenia po zawinięciu.

Może to wynikać ze sposobu, w jaki klawisze Escape są skonfigurowane w twoim terminalu, zwykle używam lewej lub prawej strzałki na iTerm lub Terminal.app, ponieważ nie jestem fanem natychmiastowego powrotu, czy to działa dla ciebie? ?

Inną możliwą przyczyną tego problemu jest niewłaściwa TERMwartość. Na przykład zdarzyło mi się to, kiedy korzystałem z kolorów na PS1, ale mój TERMbył ustawiony xterm. Zmieniłem to na, xterm-256colora następnie CTRL-r znów zaczął działać poprawnie.