Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

what means this piece of code

Status
Not open for further replies.

toaran

Technical User
Nov 19, 2002
8
0
0
DE

hi
i found this piece of code inside a proc but i don't know what "expect *" means ...


expect {
-re ".*" {
expect *
set temp1 $expect_out(buffer)
# puts "\n--flash_gb2pp:--\n$temp1\n"
}
}
 
Expect is a Tcl extention in wide use for testing. I comes with the ActiveState installation and has extensive help files. Bob Rashkin
rrashkin@csc.com
 
Expect is an extension to tcl to automate interactive applications.

What the code does is a regexp wait for anything from the
spawned process, then it does a glob expect after this(probably unnecessary)anything, sets the variable
temp1 to all input matching in the internal expect
(glob style) segment and then does some weirdness
with puts which just prints some info I guess, to
stdout.
 
For more information on Expect, check out the official Expect web site, You might also want to go to the Tcl'ers Wiki ( which has several pages on the Expect extension. I'd recommend starting with the "Expect" page, - Ken Jones, President, ken@avia-training.com
Avia Training and Consulting, 866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax
 
By the way, taking a second look at the code fragment, if that's the way it actually appears, then it's really bad code. I'd be surprised if it actually does anything useful.

The [tt]-re ".*"[/tt] pattern should match all characters that Expect has received from the spawned process, storing the characters matched in expect_out(0,string) (as well as expect_out(buffer), in this particular case). The inner [tt]expect *[/tt] then attempts to do exactly the same thing. However, the outer expect command has already consumed all of the characters Expect has received from the spawned process, and the inner expect command will never cause Expect to attempt to read more characters from the process. Therefore, the inner expect command will always match an empty string, which will be stored in expect_out(0,string) and expect_out(buffer).

It seems as though the person who originally wrote this code had little understanding of how Expect works. I'd highly recommend getting Don Libes's Exploring Expect book. If you've inherited this code, I suspect that it's going to take a lot of sifting through the code, debugging and rewriting it to get it to work properly. - Ken Jones, President, ken@avia-training.com
Avia Training and Consulting, 866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax
 
I think that the first segment will match the first 'char'
of output and the inner segment will match any single
'char' thereafter.
In my analysis, I didn't go as far in to the critical
end as you ;), but noticed that it was essentially super
fluous coding and noted to myself that it wasn't really
well done.

As an experiment I replicated the original code
using ping:
Code:
#!/usr/bin/expect
exp_internal 1
spawn ping [lindex $argv 0]
set cnt 0

  expect {
 
         -re ".*" {
              incr cnt
              send_user "Dumping expects buffers at $cnt \n\n"
              parray expect_out
              send_user "Ending segment\n\n"
                 expect -gl "*" {
                             if {$cnt < 10} {
                             incr cnt
              		     send_user &quot;Dumping expects buffers at $cnt \n\n&quot;
              		     parray expect_out
                             after 1500 ; exp_continue  
                             }
                            send_user &quot;Ending segment\n\n&quot;
                 }
           }
          close $spawn_id ; wait
   }

The OP is predictable:
spawn ping skrg
parent: waiting for sync byte
parent: telling child to go ahead
parent: now unsynchronized from child
spawn: returns {18716}

expect: does &quot;&quot; (spawn_id exp4) match glob pattern &quot;*&quot;? yes
expect: set expect_out(0,string) &quot;&quot;
expect: set expect_out(spawn_id) &quot;exp4&quot;
expect: set expect_out(buffer) &quot;&quot;
Dumping expects buffers at 3

expect_out(0,string) =
expect_out(buffer) =
expect_out(spawn_id) = exp4
Ending segment

expect: continuing expect

expect: does &quot;&quot; (spawn_id exp4) match glob pattern &quot;*&quot;? yes
expect: set expect_out(0,string) &quot;&quot;
expect: set expect_out(spawn_id) &quot;exp4&quot;
expect: set expect_out(buffer) &quot;&quot;
Dumping expects buffers at 4

expect_out(0,string) =
expect_out(buffer) =
expect_out(spawn_id) = exp4
Ending segment

etc..

However changing the inner segment to:
expect -re &quot;(.*)\n&quot;..yields satisfactory results:
expect: does &quot;&quot; (spawn_id exp4) match regular expression &quot;(.*)\n&quot;? no
64 bytes from 192.168.1.45: icmp_seq=13 ttl=255 time=0.592 ms

expect: does &quot;64 bytes from 192.168.1.45: icmp_seq=13 ttl=255 time=0.592 ms\r\n&quot; (spawn_id exp4) match regular expression &quot;(.*)\n&quot;? yes
expect: set expect_out(0,string) &quot;64 bytes from 192.168.1.45: icmp_seq=13 ttl=255 time=0.592 ms\r\n&quot;
expect: set expect_out(1,string) &quot;64 bytes from 192.168.1.45: icmp_seq=13 ttl=255 time=0.592 ms\r&quot;
expect: set expect_out(spawn_id) &quot;exp4&quot;
expect: set expect_out(buffer) &quot;64 bytes from 192.168.1.45: icmp_seq=13 ttl=255 time=0.592 ms\r\n&quot;

As would just cutting out the inner segment and using
a more concise pattern and exp_continue.

Seeya.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top