Eli*_*ria 7 command-line shell terminal stty
我最近在运行tail -f的服务器的日志文件上运行，试图诊断错误，当我不小心撞到键盘并输入了一些字符时。它们与日志的输出混合在一起，无法分辨哪个是哪个。我已经无数次发生过类似的恼人的事情，我相信这里的许多其他人也发生过这种情况。
所以我的问题是：为什么 shell（或终端，或任何正在执行的操作）模糊地将键盘输入与命令输出混合在一起？
我不是在寻求针对眼前问题的实际解决方案。我也许可以想出某种方法让 shellstty -echo在命令运行和stty echo完成时运行。但我想知道设计这样的终端背后的基本原理。有什么实际目的吗？或者它只是出于兼容性原因而做的事情，还是根本没有考虑过的事情？
人们通常想看看他们在输入什么（除非是密码）:-)
终端随时接受输入，并缓冲它直到应用程序读取它。更重要的是，当 tty 处于熟模式时，内核一次缓冲整行并提供一些基本的行编辑功能，允许您终止整个缓冲行（默认绑定Ctrl-u和退格。在该行处于正在输入和编辑，直到您按下Enter，从终端读取的应用程序才读取任何内容。
内核中的 tty 功能不知道，也不知道像这样的应用程序是否以及何时tail计划在终端上生成输出，因此它无法以某种方式...取消（？）行编辑在这种时间并且仅在这样的时候。
无论如何，能够在终端上仍然忙于运行其他东西并且 shell 尚未准备好读取该命令时为 shell 准备下一行是一个功能，而不是一个错误，所以我不主张删除它。对于tail（永远不会自行终止）可能不是那么有用，但是在长时间运行cp或make（例如）期间预先输入下一个命令，甚至编辑该命令Ctrl-h和Ctrl-u，所有这些都是在 shell 获得之前它，是很常见的事情。蒂莫西·马丁在评论中写道：
值得一提的是
less +F somefile，tail -f somefile除了（意外）键入的按键不会显示echo在屏幕上之外，它提供了类似的功能。
是的，但less不仅防止这些字符被回显，而且还会吃掉它们，因此下一个想要读取它们的应用程序无法使用它们！
最后，还有一个原因：
在历史时期（在我的时代之前！）具有本地回声的终端很常见。也就是说，终端（通常在硬件中）会回显您在本地输入的字符，同时还将它们发送到串行线路上。即使在连接到 UNIX 系统时有很多延迟，这对于给用户快速反馈也很有用（想想300 波特调制解调器通过自动远程登录将终端服务器拨号到一个缓慢的 UNIX 系统，通过令牌环网络——或者其他什么）。
如果您有一个带有本地回显的终端，那么您希望stty -echo始终在您所连接的 UNIX 服务器上。结果与终端大致相同没有本地回声（今天常见的类型）并stty echo启用。因此，从这个角度来看，stty echo的工作是在接收到字符后立即回显，无论正在运行什么软件，以模拟终端上会发生的本地回声。
（顺便说一句，如果你有一个带有本地回显的终端，你就不能隐藏你的密码。）
