왜 이런 일이 발생하는지, 심지어 무엇을 검색해야 하는지 이해할 수 없는 것 같습니다.
두 개의 비디오에서 문제를 보여줍니다.
- https://www.loom.com/share/7497428d757e45399faa5ebcf391e1be
- https://www.loom.com/share/456944568b3b4eb4ac563cd6c4a6fc03
기본적으로 편집하는 동안 삭제나 백스페이스를 누르면 vi
다음과 같은 횡설수설이 발생합니다.
^@?^D?@I_?^@S܅^@^@^@^@ M-?pK_?pK_?^P^@^@^@
^@^@^@?7C^@^@2C^@?,C^@?,C^@?,C^@@7C^@^A^\^@^P^F^@^@^@@I_?^@S܅^@r???^V^X?^@^@^@^@?c-?^@^@^@^@^F^@^@^@` Z?@I_?@I_?^T62?^@^@^@^@$?%?^H???^@^@^@^@^@^@^@^@^@^@^@^@%^B^@^@^@^@^@
^@^@^@^P'^@^@d^@^@^@^C^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P???^P???^@^@^@^@??^N?L<Y?^A^@^@^@^C^@^@^@^A^A^@^@^@^@^@^@^Y^@^@^@^@^@^
# uname -a
Linux openmiko 3.10.14 #1 PREEMPT Sun Nov 1 02:58:54 UTC 2020 mips GNU/Linux
# env
SSH_CLIENT=192.168.0.133 65524 22
USER=root
SHLVL=1
HOME=/root
SSH_TTY=/dev/pts/0
PAGER=/bin/more
PS1=#
LOGNAME=root
TERM=xterm-256color
PATH=/bin:/sbin:/usr/bin:/usr/sbin
SHELL=/bin/sh
PWD=/root
SSH_CONNECTION=192.168.0.133 65524 192.168.0.174 22
EDITOR=/bin/vi
나는 wchar 지원을 비활성화했기 때문에 이것이라고 생각했지만 그렇지 않았습니다.
새 파일에서 이것을 재현할 수 없는 것 같습니다. 그러나 기존 파일을 편집하면 해당 문제가 발생하는 것 같습니다. 그것은 모두 zram 시스템에 있습니다.
테스트 에 사용하는 것은 vi
busybox로 컴파일됩니다.
# vi -h
BusyBox v1.24.1
vi로 새 파일을 만들어서 붙여넣으면 잘 되는 것 같습니다. 써보니 정확하게 적혀있네요. 그런데 다시 편집을 해보니 부패한 부분이 발견되었습니다.
답변1
확실하게 말할 수는 없지만 "귀하의 구체적인 경우에는엑스"특히 귀하의 환경을 정확하게 재현할 수 없다는 점을 감안할 때 귀하의 문제에 대한 정보를 바탕으로 검색하도록 안내할 수 있다고 생각합니다. 아마도 이것이 귀하가 기대하는 대답은 아닐 수도 있지만 그렇게 될 것이라고 생각합니다." 적절한 지식 인간은 자신의 환경을 재현할 수 없으면 많은 것을 찾을 수 없으므로 도구 사용에 영향을 줄 수 있는 다양한 요소에 대해 논의하여 문제를 스스로 찾을 수 있도록 노력하겠습니다.
예비 고려 사항
일부 세부 사항은 중요하지 않은 것처럼 보일 수 있지만 경험하는 내용에 영향을 미칠 수 있습니다.
1. Busybox는 vi
전자가 아닙니다.vi
하나의 이름이 수십(또는 수백)의 다른 것을 나타낼 수 있기 때문에 이야기하기가 vi
어렵습니다 . Bill Joy가 유지 관리를 중단했을 때 많은 사람들이 별도로 작업하고 유지 관리하기 시작했기 때문에 vi
여러 장소가 있었습니다. 분명히, 한 사람에게는 효과가 있는 것이 다른 사람에게는 효과가 없을 수도 있습니다.
그리고 어느 시점부터 vi
엘비스 프레슬리처럼 '클론'이 나타나기 시작했습니다. 복제는 완전히 다른 코드베이스를 의미합니다. 따라서 나는 개인적으로 이 용어를 사용하여 원래 코드베이스와 Gunnar Ritter의 이후 업데이트 중 일부를 vi
나타냅니다 . vi
하지만 사람들마다 이 용어를 다른 의미로 사용할 수 있으므로 명확히 하는 것이 중요합니다.
위에서editors/vi.c
Busybox 소스 코드의 파일:
/*
* tiny vi.c: A small 'vi' clone
* Copyright (C) 2000, 2001 Sterling Huxley <[email protected]>
이것은 당신이 실행하고 있는 것이 실제로 내가 부르는 것이 아니라 vi
"작은 vi
복제품"이라는 것을 의미합니다. 이는 확실히 귀하의 경험에 영향을 미칠 것입니다. 또한 BusyBox가 미니멀리스트 시스템용으로 설계되었다는 점을 고려하면 해당 vi
복제본은 많은 터미널 변경 사항을 처리할 수 있는 능력이 가장 낮을 수 있습니다.
2. 일련의 터미널 지원 요구 사항이 있습니다.
TERM=xterm-256color
문제가 될 수도 있고 아닐 수도 있는 colors() 를 사용하여 xterm에서 이를 실행하고 있습니다 . ex - 터미널 유형 옵션을 지원하는지 여부에 따라 또는 로 컴파일 할 vi
수 있습니다 . ncurses는 현대적이고 terminfo를 사용하므로 시스템에 터미널 정보가 있는 한 작동할 수 있습니다. 그러나 termcap은 오래되고 오래된 터미널 정보 데이터베이스이므로, 그렇다면 아마도 문제를 설명할 것입니다.termcap
curses
ncurses
TERMLIB
xterm
하지만 ex- 를 실행하고 있지 않기 때문에 busybox- 가 제공하는 환경을 vi
조사해야 합니다 . vi
busybox 저장소의 특정 코드에 대한 개요를 살펴보니 vi.c
터미널 처리가 없는 것을 발견했습니다. 비지박스가 다른 곳에서 터미널을 처리하는 것 같지만 더 자세히 알아볼 시간이 없습니다.
3. vi
사용중인 키 중 일부가 지원되지 않습니다
ex-와 같은 클론을 제외하고 vi
Del, Home 등의 제어 키를 지원하지 않습니다. 따라서 이를 사용하고 있으므로 이것이 문제의 원인일 수 있습니다. 많은 사람들이 그것을 사용했거나 사용해 왔고 작동하기 때문에 전 지원을 생각할 수 있지만 이것은 패치 버전을 사용할 때의 경우입니다(Linux 배포판은 종종 ArchLinux와 같은 오래된 패키지를 패치하고 패키지를 지원 제어 키에 패치합니다.vim
vi
vi
vi
다시 말하지만, 이러한 키를 처리하는 busybox의 코드에서는 아무 것도 찾을 수 없으므로 vi.c
다른 곳의 busybox가 이를 지원하는지 확실하지 않습니다. 여전히 의심스러운 점은 x
예를 들어 Del 대신 키(다음 문자 지우기)를 사용하여 문제가 발생하는지 확인하는 것입니다. 또는 busybox 설명서에서 이 정보를 찾으세요.
가능한 이유
이제 이전 고려 사항을 바탕으로 발생할 수 있는 가능한 문제에 대해 논의해 보겠습니다. 아래 목록은 더 짧으며 확인해야 할 더 구체적이고 객관적인 문제가 있습니다.
1. 터미널 에뮬레이션 문제
저와 다른 사람들이 댓글 섹션에서 언급했듯이, busybox가 액세스할 수 있는 단말기 정보는 vi
귀하가 사용 중인 단말기 유형을 지원하지 않거나 이에 대한 정보를 가지고 있을 수 있습니다. 시도해 볼 수 있는 한 가지 방법은 그래픽 터미널 에뮬레이터(운영 체제가 지원하는 경우) 대신 실제 콘솔을 사용하는 것입니다. 또한 busybox가 vi
"terminfo" 지원이나 이를 지원하는 라이브러리로 컴파일된 경우 로컬 시스템에서 터미널 정보를 내보내고 대상에서 가져올 수 있습니다(플랫폼 차이가 시스템에 어떤 영향을 미칠지는 모르겠지만). 이것). 일부 의견에서 제안한 것처럼 Mac을 실행하고 있다면 도움을 드릴 수 없지만 Linux를 실행하고 있다면 적응하는 것이 좋습니다.이 지침귀하의 상황에 따라.
2. 프로그램은 제어 키를 지원합니다
앞서 언급했듯이, busybox는 적절한 터미널 정보 지원이 있어도 vi
이러한 키를 지원하지 않을 수 있습니다 . 또는 지원될 수도 있지만 올바른 구성이 필요하므로 비지박스 빌드 구성을 검토하는 것도 확인해 볼 가치가 있습니다.
이 경우 적절한 채널을 통해 기능 요청을 제출해야 할 수도 있습니다. 그들은 그것이 자신의 범위와 요구 사항에 맞는지 평가하고 구현할 수 있는지 여부를 평가할 수 있습니다. 또는 가능하다면 표준 키를 사용하십시오.
3.이것은 버그일 수 있습니다.
의견에서 제안한 대로 RAM 문제가 있을 수 있다고 생각하기 전에 버그 가능성을 고려해 볼 수도 있습니다. 일반적으로 소프트웨어 오류는 하드웨어 오류보다 발생할 가능성이 더 높습니다. 원인을 찾을 수 없고 말씀하신 것처럼 재현이 가능한 경우 이 가능성을 고려해 볼 수 있습니다. 문서에서 아무것도 찾을 수 없고 다른 모든 가능성이 소진된 경우 버그 보고서를 제출하는 것이 좋습니다.
busybox는 vi
매년 매우 적은 수의 커밋을 받으며 어떤 이유로든 많은 유지 관리를 받지 못할 수 있습니다.
4. 코딩 문제?
댓글에서 인코딩 문제가 무시된 것을 확인했습니다. 이것이 다소 어렵다고 생각하기는 하지만 이것이 배제될 수 있다고 100% 확신할 수는 없습니다. 텍스트가 ASCII로 나타나더라도(예를 들어 UTF-8이 지원됨) LANG 또는 기타 로케일 관련 환경 변수가 설정되지 않습니다. 이는 우연히 대상 시스템이 다른 인코딩을 기본값으로 사용하고 어쨌든 호환되지 않는 경우 약간의 영향을 미칠 수 있음을 의미합니다. 나는 이것이 가능성이 낮다고 생각하지만 언급할 가치가 있습니다. LANG=en_US.UTF-8
유사한 환경 변수를 사용하여 이를 테스트 실행해 볼 수 있습니다 .
위의 내용을 고려하면 이 목록이 완전한 것은 아닙니다. 어쩌면 댓글에 더 많은 정보를 추가하면 나나 다른 사람들이 알아차리고 다른 가능한 원인을 추가하는 데 도움이 될 수도 있습니다.
노트
vi
[a] 과거에 약 10년을 보낸 사람으로서( vim
2012년까지 전환하지 않았습니다) 이 문제를 수백만 번 보았습니다. 그러나 귀하의 상황은 다른 것 같습니다. 어쨌든 나는 이 질문에 답할 필요를 느낀다.