鉴于控制字符通常不会被渲染,但在大多数终端中它们被赋予了特殊的含义,那么终端应用程序继续支持控制字符复制粘贴的原因是什么?
例如,可以按照此处所述屏蔽有害代码,以便在粘贴到终端时引起问题。
导致这种情况的问题是双重的:
- Chrome 不呈现 ^H 字符,让人期待复制的文本是不同的。
- gnome-terminal(或 xterm)尽职尽责地从用户那里接受它,就好像它是直接键盘输入一样,执行控制字符
为什么终端会这样做?是否有能够将控制字符(\t、\r、\n 除外)粘贴到终端的用例?
鉴于控制字符通常不会被渲染,但在大多数终端中它们被赋予了特殊的含义,那么终端应用程序继续支持控制字符复制粘贴的原因是什么?
例如,可以按照此处所述屏蔽有害代码,以便在粘贴到终端时引起问题。
导致这种情况的问题是双重的:
为什么终端会这样做?是否有能够将控制字符(\t、\r、\n 除外)粘贴到终端的用例?
终端提前复制和粘贴。因此,在终端协议中,粘贴与键入之间没有区别。将内容粘贴到终端仿真器窗口的想法通过在“粘贴”功能激活时模拟终端时的字符快速键入来改进到系统中。这只是完全按照剪贴板中的内容转储内容。
至于粘贴控制字符:终端仿真器的程序员的反应大概是“你为什么要那样做?” 您提出了一个令人信服的论点,即这实际上可能是终端程序本身的注入漏洞。
因此,建议像 PuTTY 和 GNOME Terminal 这样的程序应该在某处设置一个允许您指定是否要启用控制字符粘贴的设置并不是不可能的。可能默认禁用。
我相信这是一个很好的问题,因为它涉及到很多系统。球在哪个球场?这真的是个问题吗?我从来没有想过这个,但让我吐出一些想法。
我相信复制和粘贴是一种工具,并且由于它是一种工具,因此我相信将控制字符从一个地方复制并粘贴到另一个地方可能很有用。例如,您可能想复制一个 shell 脚本配方并将其粘贴到您的终端或“笔记应用程序”中。
关于安全隐患。当然有,你可能正在复制一些你不知道它是否有害的东西,实际上它是隐藏的,所以它可以欺骗高级用户所以,这就像在复制/粘贴控制字符时添加警告一样简单吗?是否应该在找到控制字符时绘制特殊字符串?好吧,我想这将取决于我们考虑的应用程序。
我希望这个答案能激发其他人表达内心的想法,如果我觉得可以添加一些更有价值的想法,我会升级这个答案。
终端允许任意输入,因为它们正是:终端。它们模拟通过串行线路工作的旧物理设备。复制粘贴只是被强行推入该模型,没有真正考虑安全性。
事实上,在旧的 Unix+X11 模型中,通过防止外人发送合成事件来确保安全性。用户本人复制粘贴恶意数据片段并不被视为威胁。
如果发生一些实际攻击,终端将开始注意,迫使开发人员采取行动以避免被嘲笑。
关于:
是否有能够将控制字符(\t、\r、\n 除外)粘贴到终端的用例?
您与TUI的交互是通过这些控制字符进行的。能够粘贴它们意味着您可以使用此功能半自动化您与 TUI 程序的交互。
前段时间,我节省了我的部门许多小时的匆忙工作,即通过从 CSV 中获取我们需要输入的数据,插入导航 TUI 所需的控制字符(通过sed
I think),验证结果并将其粘贴到终端中。一切都需要几分钟。
向他们展示这就像在 TUI 程序的每一种形式中添加一个导入功能。他们发现这是一种非常有用的技术,可以真正节省时间。
不过,根据具体情况,这可能有点危险。如果输入值无效或控制顺序错误,TUI 程序响应异常,粘贴不会退出;它会继续运行,谁知道 TUI 程序会做什么。
在我们的例子中,确保输入有效很简单,测试一个循环(足够粘贴输入 1 条记录并返回起始位置)也足以确保控制字符正常,我们还采取了如果在任何时候都可以断章取义地解释这种特殊的粘贴,那么现在需要考虑可能发生的最坏情况。
对于一个罕见的问题,这是一个快速而肮脏的临时解决方案。如果有更多时间,最好先学习如何编写expect
脚本以至少在第一个检测到的错误时退出并报告它卡在哪里。不过我们有点着急,所以我们不能考虑需要先花时间学习的东西,尤其是当我们已经接受手动完成需要多长时间的时候。在几分钟内粘贴我们与 TUI 的交互的简单性和易用性是使用expect
脚本提供的价值。