☰

初步考虑

tag-icon • tag-icon terminal escape-characters busybox special-characters
初步考虑

我似乎不明白为什么会发生这种情况，甚至不知道要搜索什么。

两个视频演示了该问题：

  1. https://www.loom.com/share/7497428d757e45399faa5ebcf391e1be
  2. 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

虽然我不能肯定：“就你的具体情况而言，是由X“，特别考虑到我无法完全重现您的环境，我认为我能够[a]指导您对问题进行明智的搜索。可能这不是您期望的答案，但我认为您会的”除非具有适当知识的人能够重现您的环境，否则不会找到太多内容，因此我将尝试讨论可能影响您使用该工具的各种因素，以便您自己找到问题。

初步考虑

有些细节可能看起来无关紧要，但可能会对您所经历的事情产生影响。

1. Busyboxvi并非前vi

谈论vi是很棘手的，因为一个名字可能指的是几十个（甚至数百个）不同的事物。当 Bill Joy 停止维护它时，许多不同的人开始分别工作和维护它，这就是vi存在几个不同的地方。显然，适用于一个的可能不适用于另一个。

此外，在某个时候，vi“克隆人”开始出现，比如猫王。克隆意味着它是一个完全不同的代码库。因此，我个人使用这个术语vi来指代vi原始代码库以及 Gunnar Ritter 后来的一些更新。但不同的人可能会使用该术语来表示不同的事物，因此明确说明很重要。

从顶部editors/vi.cBusybox源代码中的文件：

/*
 * tiny vi.c: A small 'vi' clone
 * Copyright (C) 2000, 2001 Sterling Huxley <[email protected]>

这意味着您正在运行的实际上并不是我所说的vi，而是一个“小vi克隆”。这肯定会影响您的体验。另外，考虑到 BusyBox 是为极简系统而设计的，因此它们的vi克隆可能不是最有能力处理很多终端变化的。

2. 存在一系列的终端支持需求

您正在将其运行到带有颜色 ( ) 的 xterm 中TERM=xterm-256color，这可能是问题，也可能不是问题。 ex-vi可以使用termcap,curses或ncursesas进行编译TERMLIB，具体取决于它支持或不支持终端类型的选项xterm。由于 ncurses 是现代的并且使用 terminfo，因此只要系统具有其终端信息，它就可能起作用。但 termcap 是一个古老且过时的终端信息数据库，因此如果是这样的话，它很可能会解释您的问题。

但由于您没有运行 ex- vi，因此您必须研究 busybox-vi为您提供的环境。我对 busybox 存储库中的特定代码进行了概述vi.c，并发现其中没有对终端进行处理。我猜想 busybox 在其他地方处理终端，但没有时间了解更多信息。

3.vi不支持您正在使用的某些按键

不包括像、 ex-vi这样的克隆，不支持 Del、Home 等控制键。因此，既然您使用了它们，这可能是问题的根源。许多人可能认为 ex-支持它们，因为他们使用或曾经使用过它并且它们工作了，但使用修补版本时就是这种情况（Linux 发行版经常修补这种旧软件包，例如 ArchLinux，修补软件包以支持控制键。vimvivivi

同样，我在 busybox 的代码中找不到任何处理此类键的内容vi.c，因此我们不确定其他地方的 busybox 是否支持它。仍然有疑问，您可能会尝试做的一件事是使用x键（擦除下一个字符）作为 Del 的替代品，例如，看看问题是否发生。或者在 busybox 的文档中找到这些信息。

可能的原因

现在，基于之前的考虑，我们来讨论一下可能出现的问题。下面的列表较短，有更具体和客观的可能问题需要检查。

1. 终端仿真问题

正如我和其他人在评论部分提到的，busybox 可以访问的终端信息vi可能不支持或不具有有关您正在使用的终端类型的信息。您可以尝试的一件事是使用实际的控制台而不是图形终端模拟器（如果您的操作系统支持的话）。另外，如果 busybox 的vi编译支持“terminfo”或支持它的库，您可以尝试导出本地系统上的终端信息并在目标上导入（尽管我不确定平台差异可能会对此产生任何影响） ）。如果你按照一些评论的建议运行 Mac，我无法帮助你，但如果你运行 Linux，你可能想要适应这些说明根据你的情况。

2.程序对控制键的支持

如前所述，即使有适当的终端信息支持，busybox 也vi可能不支持此类键。或者，它可能支持但需要正确的配置，因此对 busybox 构建配置的审查也可能值得检查。

如果是这种情况，您可能需要通过适当的渠道提出功能请求。他们可能会评估它是否适合他们的范围和要求，并可能实施（或不实施）。或者，如果您可以的话，也可以使用标准按键。

3.这可能是一个错误

在认为您可能存在评论中建议的 RAM 问题之前，也可能会考虑存在错误的可能性。软件错误通常比硬件故障更容易发生。如果您找不到原因，并且它可以像您提到的那样重现，则可以考虑这种可能性。如果您在文档中没有找到任何内容并且所有其他可能性都已用尽，我建议您提交错误报告。

busyboxvi每年收到的提交很少，可能会因为某种原因而没有收到太多维护。

4. 编码问题？

我注意到评论中忽略了编码问题。虽然我觉得这有点困难，但我不能 100% 确定可以排除这种情况。虽然文本似乎是 ASCII（因此例如支持 UTF-8），但没有设置 LANG 或其他与语言环境相关的环境变量。这意味着，如果万一您的目标系统使用另一种编码作为默认值并且无论如何不兼容，它可能会产生一些影响。我认为这不太可能，但值得一提。您可能想使用LANG=en_US.UTF-8类似的环境变量来测试运行它。

鉴于上述情况，这个列表显然并不详尽。也许在评论中添加更多信息可能会帮助我或其他人注意到并添加其他可能的原因。

笔记

vi[a] 作为一个过去花了大约 10 年时间使用的人（我vim直到 2012 年才切换到），我已经看到这种问题数百万次了。不过，你的情况似乎有所不同。不管怎样，我觉得有必要回答这个问题。

相关内容