这是我找到的可以解答我的问题的最佳地方。
从 gitbash 内部运行vim | less会导致它执行一些我只能形容为“中断”的操作。
通常我可以恢复 less 提示符，有时可以恢复 vim 提示符，很少恢复 shell 提示符；只有 shell 提示符看起来正常，但您无法输入命令。
另外，您通常是否只能选择整行？哦，那是因为我在空行上进行测试。
回到我的问题：
为什么会发生这种情况？如何预防？
答案1
发生这种情况是因为您正在运行两个不同的程序，它们想要并行控制您的终端，而且它们都没有理由自行退出。
当您通过管道运行两个命令时，bash 会将第一个命令的标准输出连接到管道，然后将其连接到第二个命令的标准输入。然后它将并行运行这两个程序。在管道中，所有命令都并行运行，而不是按顺序运行。
因此，vim 在其标准输出中写入的任何内容，都可以在其标准输入中为 less 所用。
但 vim 实际上不会在标准输出上产生任何东西。由于它是一个全屏程序，它会尝试找到您的终端（或tty）连接到的位置，并尝试控制它，在那里绘制它的 UI 并从那里获取击键。
less 类似，它会找到终端并使用它来控制屏幕。
Vim 不会生成任何标准输出，但 less 无法分辨，并将保持与管道的连接，等待任何行的到来。Vim 不会真正关闭标准输出上的管道，因此 less 将继续尝试从中读取。
您要与哪个程序交互，嗯，这是一个竞争条件。两个程序并行启动，都需要您的终端，因此最先获得终端的程序获胜（或者最后一个获胜？可能是最后一个击败了第一个？）
无论如何，它都不会是 bash，因为 bash 正在等待管道完成，所以在运行的程序终止之前它不会显示另一个提示。
这应该可以解释发生了什么。我不确定你用 想干什么vim | less，但除了关于管道和ttys 的理论讨论之外，该命令实际上没有任何用处……关于“如何防止这种情况”的最佳答案很简单：不要运行该命令！
如果您尝试使用 完成某件特别的事情vim | less，那么请描述您尝试使用这些命令做什么（也许在单独的问题中），您应该会得到一个更好的答案，关于如何完成您正在尝试做的事情。
答案2
为什么不直接使用less？假设您使用 vim 作为默认编辑器，您可以按“v”键less在 vim 中查看文件。（唯一的潜在问题是，当您退出 vim 时，它会将您转回less。）