(내가 아는 한 "xyz"는 .zshrc의 첫 번째 줄에 있는 모든 것이 될 수 있습니다. .zshrc의 첫 번째 줄에 있는 빈 줄이라도 터미널을 열 때 동일한 출력을 반환하지만 공백으로 끝납니다. 또한 시도해 보았습니다. 어딘가에서 찾을 수 있는 모든 터미널 입력 인스턴스를 고려하면 pwd이것이 가장 다재다능한 명령 중 하나라고 생각했지만 역시 찾을 수 없었습니다.
나는 이 문제가 전적으로 내 .zshrc 파일의 변경으로 인해 발생했다고 확신합니다. 왜냐하면 .zshrc와 oh-my-zsh 사이의 별칭 충돌과 관련된 이전 문제에 대한 수정 사항을 테스트하기 위해 터미널을 조정/닫고 열었기 때문입니다. 몇 시간 전에 문제가 발생했습니다. 즉, oh-my-zsh가 .zshrc의 사용자 정의 별칭보다 우선순위를 갖는 특정 파일을 가져오기 위해 행을 추가했다는 사실을 몰랐습니다. 링크를 참조하세요.내 .zshrc 파일을 "소싱"해도 별칭이 변경되지 않는 이유는 무엇입니까?).
잠재적으로 관련이 있거나 일반적으로 유용한 정보:
- gnome 터미널(선호되고 거의 독점적으로 사용됨)과 urxvt(백업) 모두에 문제가 있습니다. -지속되는 첫 번째 딸꾹질을 제외하고 모든 것이 잘 작동합니다. 내 모든 별칭과 oh-my-zsh 구성표도 제대로 작동합니다.
– fortune -o이것이 해결책을 찾기 전에 제가 처음으로 한 말입니다. (역시 돌아왔습니다 command not found: fortune)
--위 링크에 언급된 문제를 해결하기 위한 마지막 시도는
source $home/.zshrc
다음을 포함하는 줄 바로 아래source $ZSH/oh-my-zsh.sh
이것의 이면에 있는 아이디어는 source내 사용자 정의 .zshrc 파일을 사용하면 해당 파일의 별칭이 oh-my-zsh 파일에 의해 결정된 모든 별칭보다 우선하게 된다고 생각했다는 것입니다. 이것이 어떻게 작동하는지/이해/어떻게 하는지 잘 모르겠습니다. 우선 거기에 도착했습니다. 파일을 저장하고 별칭 변경 사항을 테스트하기 위해 터미널을 닫고 새 터미널을 연 후 매우 혼란스러운 오류가 나타났습니다. 터미널은 정상적으로 열리고 색 구성표와 그 밖의 모든 것이 미학적으로 정확하지만 상당히 빠른 속도로 끝없이 무작위 운명을 반복하고 있습니다. 이를 방지하기 위한 일반적인 키 바인딩(Ctrl+C, Ctrl+D, Esc, Enter, "Q")은 없습니다. 그래서 그것을 끄려면 그놈 키 바인딩을 사용해야 했습니다. urxvt의 버그는 정확히 같은 방식으로 지속됩니다. 이 source $home/.zshrc선을 제거하면 순환 부 문제가 해결되었지만 현재의 난제는 발생했습니다.
답변1
전체 질문은 두 가지 합병증에 달려 있습니다. 첫 번째는 저의 어리석은 실수였습니다. 저는 스크립트 source자체를 가질 수 있다고 생각했습니다. 다른 상황에서는 이것이 가능할 수도 있지만 제 특별한 경우에는 .zshrc 호출이 무한 루프로 이어졌습니다. 두 번째 문제는 첫 번째 문제를 해결하려는 시도가 실패하여 발생합니다. 즉, libreoffice를 사용하여 시스템 구성 파일을 편집하는 것입니다. 무한한 스크립트 호출로 인해 모든 터미널이 비활성화되었으며 다른 GUI 텍스트 편집기를 사용할 수 없으므로 libreoffice가 한 줄 변경 편집에 적합하다고 생각합니다. 텍스트 파일을 저장할 때 libreoffice는 바이트 순서 표시(https://en.wikipedia.org/wiki/Byte_order_mark). 나는 그것에 대해 많이 알지 못하지만 vim 명령 없이는 기본 vim 편집기가 명확한 방식으로 표시하지 않는다는 것을 확실하게 말할 수 있습니다.
그러나 vim에서는 위 BOM을 삭제할 수 있습니다. 현재 파일에 BOM이 있으면 :set bomb?출력됩니다. bomb대신 nobomb존재하지 않으면 반환됩니다.
직관적으로 vim에게 삭제를 요청할 수 있습니다.:set nobomb
그러나 나중에 파일을 저장하는 것을 잊지 마십시오. 그렇지 않으면 변경 사항이 발생하지 않습니다.