Windows的“choice”命令影响了Ruby的“gets”方法

Question

打开irb并执行以下操作：

1. 输入gets。它应该可以正常工作。
2. 然后尝试 system("choice /c YN")，它应该按预期工作。
3. 现在再次尝试gets，它的行为很奇怪。

有人能告诉我这是为什么吗？

编辑：为了澄清“奇怪”的行为，它允许我输入gets，但不显示字符，我必须按两次回车键。

- itdoesntwork

---

你应该更清楚地了解这种奇怪行为的本质。我试过了，发现除非我在运行system("choice /c YN")命令后按两次回车键，否则它不会接受数据。有时候也会多输入一个字母。你那边是不是也是这样的情况？ - KChaloux

@KChaloux 是的，那正是发生的事情。我会编辑我的帖子以包含这些细节。 - itdoesntwork

很奇怪，Windows 几乎从不出错。 - Dave Newton

@itdoesntwork 感谢您的编辑。我希望我能够解释这个现象，但我有一种预感它可能与Windows有关，而我对批处理脚本的内部工作原理并不是特别熟悉。 - KChaloux

也许它会预测另一个回车符？我假设这是使用MRI吗？ - rogerdpack

Windows还在等待您从以前的选择中选择某些内容吗？ - rud3y

Answer 1

终端的输入输出处理是一种神秘而深奥的艺术。任何试图通过ssh使bash在Windows PowerShell中工作并实现带颜色的输出的人都知道这一点。 （而各种快捷方式，如Ctrl + Backspace只会让事情变得更糟。）

你遇到问题的可能原因之一是特殊字符的处理。每个终端都可以以多种不同模式输入字符，并解析其自己的输出以寻找某些字符序列，以切换状态。

例如，这里可以找到ANSI转义代码序列，这是不同种类终端之间可能支持的标准之一。

看到那里的Esc[5;45m了吗？那将使所有接下来的输出闪烁在品红背景上。还有很多类似的内容。

因此，如果你的问题字面意思上理解，你的choice命令使用特殊的转义序列搞乱了输出模式，而ruby的gets则无法在终端操作的奇怪特殊模式下正常运行。

但更有用的将是链接到HighLine gem文档。为什么要实现特定于平台和侵入式行为，当可以使用约12 LOC实现相同的功能呢？对于Gist的所有尊重都归功于botimer，我只是在搜索中偶然发现了他的代码。

- kirushik