OS X에서 CTRL-r이 이상하게 동작하는 이유 (명령의 일부만 표시)


10

Ctrl+ r.bash_history이전에 실행 한 명령 을 검색하는 훌륭한 도구입니다 .

그러나 OS X Terminal.app에서 사용하면 이상한 동작이 표시되며 다른 사람이 같은 것을 보거나 수정하는 방법을 알고 있는지 궁금합니다.

  1. Ctrl+r
  2. 같은 것을 입력하십시오 find
  3. 오 쿨, 봐봐 ... 내가 원하는 명령이야 find . -exec grep -q "hello world" '{}' \; -print
  4. 그 명령을 실행하고 싶지만 hello world를 다른 것으로 변경하십시오.
  5. 나는 명중 그래서
  6. 이제 명령은 그렇다고 명령 행에 있지만 항상 다음과 같이 명령의 일부 trunctated 버전처럼 보인다 : -q "blog_posts_by" '{}' \; -print전체 명령이있는 곳, 내가 아니라 모든 라인에 이동할 커서 키를 사용할 수 있습니다 인쇄됩니다. 라인에 표시된 것과 터미널이 실제로 편집하고 있다고 생각하는 것 사이에 연결이 끊어졌습니다.

왜 이런 일이 일어날 지 힌트가 있습니까? 웹을 검색하는 것은 쉬운 현상이 아닙니다.


이것은 용어 창 너비보다 긴 줄에서만 발생합니까?
Essobi

BTW를 실행중인 Terminal.App/OSX의 버전은 무엇입니까? 배쉬 버전? .bashrc도 보여줄 수 있습니까?
Essobi

답변:


14

프롬프트에서 색상이 올바르게 구분되지 않은 이스케이프 시퀀스가있을 수 있습니다. 그들은 안에해야 \[하고 \].

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

인쇄되지 않은 문자 시퀀스의 길이는 프롬프트에 포함되어있을 때 프롬프트의 길이에 포함되지 않으며 랩핑시 올바른 표시를 위해 이전 명령의 위치를 ​​계산해야합니다.


- OK,이 StackOverflow의 스레드에 걸쳐 답변자에 의해 해결 된 몇 가지 더 문제가 있었다 stackoverflow.com/questions/35563/...
브라이언 케네디

이 줄 바꿈 적용 너무 프롬프트. hicolor 제어 시퀀스가 ​​시작 부분에 있었기 때문에 삭제 PS1되었지만 다시 줄 바꿈 문자 뒤에는 없었습니다.
Walf

0

이것은 터미널에서 이스케이프 키가 구성되는 방식 때문일 수 있습니다. 일반적으로 iTerm 또는 Terminal.app에서 왼쪽 또는 오른쪽 화살표를 사용하면 반환을 즉시 치는 팬이 아니기 때문에 작동합니다. ?


0

이 문제의 또 다른 원인은 잘못된 TERM값입니다. 예를 들어, PS1에서 색상을 사용할 때이 문제가 발생했지만 TERM로 설정되었습니다 xterm. 로 변경 xterm-256color한 다음 CTRL-r이 다시 올바르게 작동하기 시작했습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.