Question

我使用的代码是我的另一个人（我们称之为Code.x），它具有非常繁琐的交互式命令行界面。我经常使用这段代码执行重复的过程，理想情况下我想自动执行这些任务。

代码A要求我为要输出的文件命名，然后如果该文件名存在，它会询问我是否要覆盖。

在这种情况下，我编写了一个期望脚本，用于浏览Code.x中的用户提示：

#!/usr/bin/expect
spawn Code.x

set timeout 5
...[code]...
expect "file name" {send "foo.bar\r"} #Name of file
expect "Overwrite?" {send "y\r"} #Yes, overwrite the file
expect "Next Prompt" {send "next response\r"}
...[code]...

如果文件已存在且需要重写，则会出现重写提示，一切正常。但是，如果没有出现重写提示，而Code.x提供了Next Prompt，则在出现提示后立即出现以下错误：

wrong # args: should be "file option ?arg ...?"
     while executing
"file"
    invoked from within
"expect "Overwrite?" {send "y\r"} #Yes, overwrite the file"

如果我删除send语句周围的花括号，无论是否需要重写，代码都能正常工作。我从我读过的信息中得到的印象是大括号应该意味着只有满足expect语句才会执行send语句。如果不满足该语句，我会假设期望代码将等到达到超时，然后继续。这里到底发生了什么？

另一方面，实际上是否值得使用expect来完成这项任务？我打算将它嵌入循环中并创建许多不同的文件。

Answer 1

expect "file name" {send "foo.bar\r"} #Name of file
expect "Overwrite?" {send "y\r"} #Yes, overwrite the file

与其他语言相比，Tcl（并因此预期）评论有点奇怪。 #只是一个评论，如果它显示为单词的第一个字符，显示命令出现的位置：请参阅http://tcl.tk/man/tcl8.5/TclCmd/Tcl.htm，规则＃10

所以你想要一个显式的分号来终止命令，然后一个注释可以跟随

expect "file name" {send "foo.bar\r"} ; #Name of file
expect "Overwrite?" {send "y\r"}      ; #Yes, overwrite the file

以下是发生错误的原因：expect命令采用{pattern} {action}对列表（或包含＆＃34;模式操作＆＃34;对的单个列表）。最后一个模式不需要动作。因此，对于您的错误评论，期望看到相当于：

expect {
    "file name" {send "foo.bar\r"}
    "#Name" {of}
    "file"
}
expect {
    "Overwrite?" {send "y\r"} 
    "#Yes," {overwrite}
    "the" {file}
}

一定有＆＃34;＆＃34;＆＃34;期望在之前看到＆＃34;覆盖？＆＃34;，所以它尽职尽责地尝试执行动作块：{file}。 Tcl file command需要一个子命令，没有得到一个，并且期望抛出错误。

期待：错误#args：应该是＆＃34;文件选项？arg ...？＆＃34;

1 个答案: