使用Expect自动化测试交互式dotnet fsi程序遇阻求助

核心原因 #

dotnet fsi默认输出带ANSI颜色控制字符，这些不可见字符会干扰Expect对> 提示符的精确匹配，导致脚本一直无法找到预期的匹配项，陷入无限循环。

解决思路与步骤 #

1. 关闭dotnet fsi的颜色输出
   直接在启动时添加--nocolor参数，去除颜色相关的控制字符，这是最直接的解决方案：

   #!/usr/bin/expect -df
   
   set timeout -1
   
   spawn dotnet fsi --nocolor
   expect "> "
   send -- "let a = 3;;\n"
   expect "> "
   send -- "let b = 3*a;;\n"
   expect "> "
   send -- "#quit;;\n"
   expect eof
   

2. 使用正则匹配忽略控制字符（如果关闭颜色仍有问题）
   如果还有其他控制字符（比如光标移动序列）干扰，改用Expect的正则匹配模式，忽略所有ANSI转义序列后再匹配提示符：

   # 匹配任意数量的ANSI控制序列，然后匹配> 提示符
   expect -re {(\x1b\[[0-9;]*m)*> }
   

   替换脚本中所有的expect "> "为上述正则匹配语句，这样即使输出中夹杂控制字符，也能正确识别提示符。

3. 检查提示符差异
   手动运行dotnet fsi --nocolor，确认实际输出的提示符是否为> 。部分环境下dotnet fsi的提示符可能有细微差异（比如末尾无空格、或有其他符号），根据实际输出调整匹配模式。

4. 调试与验证
   保留Expect脚本的-d调试参数，运行时观察输出中实际接收到的字符，确认哪些控制字符在干扰匹配，针对性调整正则表达式。

内容的提问来源于stack exchange，提问作者Jon