I am a total expect noob.
I am writing a expect script for a test case where I want to count the number of occurrences of the string "Ok" and do an action for every occurrence from the following output:
Reloading configuration on all nodes
Reloading configuration on node 1 (node1-c5)
OK
Reloading configuration on node 2 (node2-c5)
OK
Reloading configuration on node 3 (node3-c5)
OK
Reloading configuration on node 4 (node4-c5)
OK
How would my expect block look like?
I'd rewrite your code to remove the while loop:
set number_ok 0
set node_patt "(Reloading configuration on node (\\d+?) \\((\[^)]+?)\\))\r\n(.+?)\r\n"
send "cluster config -r -a\r"
expect {
ERROR {cluster_exit 1}
-re $node_patt {
set line "<$cmdline> $expect_out(1,string)"
set node_num $expect_out(2,string)
set node_name $expect_out(3,string)
set result $expect_out(4,string)
switch -regexp $result {
"Node .+ not found" {
ok 0 "$line (not found)"
}
"Node .+ not responding, skipped" {
ok 0 "$line (not responding)"
}
OK {
ok 1 $line
incr number_ok
}
}
exp_continue ;# loop back to top of expect block
}
$ROOT_PROMPT ;# no action, so fall out of the expect block
}
Note that Tcl regular expressions are either entirely greedy or entirely non-greedy. I use \r\n(.+)\r\n to capture the line following "Reloading configuration on node ...". However the .+ part must not contain newlines, so it has to be non-greedy. Thus, every quantifier in node_patt has to be non-greedy.
The code ended up looking like this (a simple loop):
send "cluster config -r -a \r"
set done 0
set number_ok 0
while {$done == 0} {
set done 1
expect {
$ROOT_PROMPT { set done 1 }
"ERROR" { cluster_exit 1 }
-re "Reloading configuration on node.*\r" {
set line "<$cmdline> $expect_out(0,string)"
expect {
$ROOT_PROMPT { set done 1 }
"ERROR" { cluster_exit 1 }
-re "Node * not found" { ok 0 "$line (not found)" }
-re "Node * not responding, skipped" { ok 0 "$line (not responding)" }
"OK" {
ok 1 "$line"
set number_ok [expr $number_ok + 1]
set done 0
}
}
}
}
}
diag "Done $done"
diag "Count $number_ok"
Related
I'm modifying the code below, but I have no idea how it works - enlightenment welcome. The issue is that there is a proc in it (cygwin_prefix) which is meant to create a command, by either
leaving a filename unmodified, or
prepending a string to the filename
The problem is that the proc returns nothing, but the script magically still works. How? Specifically, how does the line set command [cygwin_prefix filter_g] actually manage to correctly set command?
For background, the script simply execs filter_g < foo.txt > foo.txt.temp. However, historically (this no longer seems to be the case) this didn't work on Cygwin, so it instead ran /usr/bin/env tclsh filter_g < foo.txt > foo.txt.temp. The script as shown 'works' on both Linux (Tcl 8.5) and Cygwin (Tcl 8.6).
Thanks.
#!/usr/bin/env tclsh
proc cygwin_prefix { file } {
global cygwin
if {$cygwin} {
set status [catch { set fpath [eval exec which $file] } result ]
if { $status != 0 } {
puts "which error: '$result'"
exit 1
}
set file "/usr/bin/env tclsh $fpath"
}
set file
}
set cygwin 1
set filein foo.txt
set command [cygwin_prefix filter_g]
set command "$command < $filein > $filein.temp"
set status [catch { eval exec $command } result ]
if { $status != 0 } {
puts "filter error: '$result'"
exit 1
}
exit 0
The key to your question is two-fold.
If a procedure doesn't finish with return (or error, of course) the result of the procedure is the result of the last command executed in that procedure's body.
(Or the empty string, if no commands were executed. Doesn't apply in this case.)
This is useful for things like procedures that just wrap commands:
proc randomPick {list} {
lindex $list [expr { int(rand() * [llength $list]) }]
}
Yes, you could add in return […] but it just adds clutter for something so short.
The set command, with one argument, reads the named variable and produces the value inside the var as its result.
A very long time ago (around 30 years now) this was how all variables were read. Fortunately for us, the $… syntax was added which is much more convenient in 99.99% of all cases. The only place left where it's sometimes sensible is with computed variable names, but most of the time there's a better option even there too.
The form you see with set file at the end of a procedure instead of return $file had currency for a while because it produced slightly shorter bytecode. By one unreachable opcode. The difference in bytecode is gone now. There's also no performance difference, and never was (especially by comparison with the weight of exec which launches subprocesses and generally does a lot of system calls!)
It's not required to use eval for exec. Building up a command as a list will protect you from, for example, path items that contain a space. Here's a quick rewrite to demonstrate:
proc cygwin_prefix { file } {
if {$::cygwin} {
set status [catch { set fpath [exec which $file] } result]
if { $status != 0 } {
error "which error: '$result'"
}
set file [list /usr/bin/env tclsh $fpath]
}
return $file
}
set cygwin 1
set filein foo.txt
set command [cygwin_prefix filter_g]
lappend command "<" $filein ">" $filein.temp
set status [catch { exec {*}$command } result]
if { $status != 0 } {
error "filter error: '$result'"
}
This uses {*} to explode the list into individual words to pass to exec.
I have expect (tcl) script for automated task working properly - configuring network devices via telnet/ssh. Most of the cases there is 1,2 or 3 command lines to execute, BUT now I have more then 100 command lines to send via expect. How can I achieved this in smart and good scripting way :)
Because I can join all command lines over 100 to a variable "commandAll" with "\n" and "send" them one after another, but I think it's pretty ugly :) Is there a way without stacking them together to be readable in code or external file ?
#!/usr/bin/expect -f
set timeout 20
set ip_address "[lrange $argv 0 0]"
set hostname "[lrange $argv 1 1]"
set is_ok ""
# Commands
set command1 "configure snmp info 1"
set command2 "configure ntp info 2"
set command3 "configure cdp info 3"
#... more then 100 dif commands like this !
#... more then 100 dif commands like this !
#... more then 100 dif commands like this !
spawn telnet $ip_address
# login & Password & Get enable prompt
#-- snnipped--#
# Commands execution
# command1
expect "$enableprompt" { send "$command1\r# endCmd1\r" ; set is_ok "command1" }
if {$is_ok != "command1"} {
send_user "\n### 9 Exit before executing command1\n" ; exit
}
# command2
expect "#endCmd1" { send "$command2\r# endCmd2\r" ; set is_ok "command2" }
if {$is_ok != "command2"} {
send_user "\n### 9 Exit before executing command2\n" ; exit
}
# command3
expect "#endCmd2" { send "$command3\r\r\r# endCmd3\r" ; set is_ok "command3" }
if {$is_ok != "command3"} {
send_user "\n### 9 Exit before executing command3\n" ; exit
}
p.s. I'm using one approach for cheeking is given cmd line is executed successfully but I'm not certain that is perfect way :D
don't use numbered variables, use a list
set commands {
"configure snmp info 1"
"configure ntp info 2"
"configure cdp info 3"
...
}
If the commands are already in a file, you can read them into a list:
set fh [open commands.file]
set commands [split [read $fh] \n]
close $fh
Then, iterate over them:
expect $prompt
set n 0
foreach cmd $commands {
send "$cmd\r"
expect {
"some error string" {
send_user "command failed: ($n) $cmd"
exit 1
}
timeout {
send_user "command timed out: ($n) $cmd"
exit 1
}
$prompt
}
incr n
}
While yes, you can send long sequences of commands that way, it's usually a bad idea as it makes the overall script very brittle; if anything unexpected happens, the script just keeps on forcing the rest of the script over. Instead, it is better to have a sequence of sends interspersed with expects to check that what you've sent has been accepted. The only real case for sending a very long string over is when you're creating a function or file on the other side that will act as a subprogram that you call; in that case, there's no really meaningful place to stop and check for a prompt half way. But that's the exception.
Note that you can expect two things at once; that's often very helpful as it lets you check for errors directly. I mention this because it is a technique often neglected, yet it allows you to make your script far more robust.
...
send "please run step 41\r"
expect {
-re {error: (.*)} {
puts stderr "a problem happened: $expect_out(1,string)"
exit 1
}
"# " {
# Got the prompt; continue with the next step below
}
}
send "please run step 42\n"
...
I have the following code for listening at a serial port:
set timeout -1
log_user 0
set port [lindex $argv 0]
spawn /usr/bin/cu -l $port
proc receive { str } {
set timeout 5
expect
{
timeout { send_user "\nDone\n"; }
}
set timeout -1
}
expect {
"XXXXXX\r" { receive $expect_out(0,string); exp_continue; }
}
Why does this give a
invalid command name "
error after the 5 second timeout elapses in the procedure? Are the nested expects OK?
The problem is this:
expect
{
timeout { send_user "\nDone\n"; }
}
Newlines matter in Tcl scripts! When you use expect on its own, it just waits for the timeout (and processes any background expecting you've set up; none in this case). The next line, with what you're waiting for, is interpreted as a command all of its own with a very strange name (including newlines, spaces, etc.) which is not at all what you want.
What you actually want to do is this:
expect {
timeout { send_user "\nDone\n"; }
}
By putting the brace on the same line as the expect, you'll get the behaviour that you (presumably) anticipate.
I dont know whats happening but i am not getting the complete output from the remote command executed possibly because expects internal buffer is getting execceded.
proc SendCommands { Commands } {
global prompt log errlog
foreach element [split $Commands ";"] {
expect {
-re $prompt
{send -- "$element\r"}
}
set outcome "$expect_out(buffer)"
foreach line [split $outcome \n] {
foreach word [regexp -all -inline {\S+} $line] {
if {( [string index [string trimleft $line " "] 0 ] == "%")} {
puts "$outcome"
exit 1
}
}
}
puts "$outcome"
}
}
set timeout 30
foreach host [ split $hosts "\;" ] {
spawn ssh -o "StrictHostKeyChecking no" "$username#$host"
match_max 10000000
expect {
timeout { send_user "\nFailed to get password prompt\n"; exit 1 }
eof { send_user "\nSSH failure for $host\n"; exit 1 }
"*?assword:*"
{
send -- "$password\r"
}
}
expect {
timeout { send_user "\nLogin incorrect\n"; exit 1 }
eof { send_user "\nSSH failure for $host\n"; exit 1 }
-re "$prompt"
{ send -- "\r" }
}
set timeout 300
SendCommands "$Commands"
}
this is how i am executing it :
./sendcommand aehj SWEs-elmPCI-B-01.tellus comnet1 "terminal length 0;show int description" "(.*#)$"
i am getting the complete output only when i remove log user 0 but when i use the puts command in the fucnction sendcommands above i get about 90 percent of it with 10 percent
of the trailing data at the end is not shown.
one way i am thinking is to use negation of regex in expect but it doesn't seem to work.
expect {
-re ! $prompt
{puts $expect_outcome(buffer)}
}
EDIT :I get all the output once when its executed about 5 or 7 times
After a little search i came up with this and seems to work but let me know of any execptions or better answers :
I set match_max = 1000 then
expect {
-re $prompt
{send -- "$element\r"}
full_buffer {
append outcome $expect_out(buffer)
exp_continue
}
}
append outcome $expect_out(buffer)
puts $outcome
but still when i set match_max = 10000 or 100 it fails again
Can anybody take a look and advice why the following snippet does not execute neither branch of the if statement? Script does not throw any errors. It simply reaches the expect line and waits until it times out.
arg1 is just an argument from command line.
set arg1 [lindex $argv 0]
set strname "teststring"
expect {
"prompt#" {
if { [string compare $arg1 $strname] != 0 } {
send "strings different\r"
} else {
send "strings same\r"
}
}
default abort
}
Thanks in advance.
EDIT:
Edited to show the correct structure.
Expect is an extension of Tcl, and Tcl is very particular about whitespace:
...
# need a space between the end of the condition and the beginning of the true block
if { [string compare $arg1 $strname] != 0 } {
...
# the else keyword needs to be on the same line as the closing bracket of the true block
} else {
...
}
Is your complete script more like this?:
#!/usr/bin/expect -d
set arg1 [lindex $argv 0]
set strname teststring
expect {
"prompt#"
if { [string compare $arg1 $strname] != 0 }{
send "strings different\r";
}
else{
send "strings same\r";
}
default abort
}
Or are you running expect some other way? How exactly are you running expect, your script, with what args?