Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
I got stuck while logon via expect!

Posted by xramm (xramm), 3 March 2008
The following script used to logon a remote office :

#!/usr/bin/expect -f

log_file /tmp/expect.LOGs
set ip [lindex $argv 0]

#setup for command to execute in cbm
set command {to send some commands to remote office}

spawn telnet $ip 2600

expect -re "Escape"
exp_send "^]\n"
expect telnet>
exp_send "send brk\n"
expect "?"
exp_send "LOGIN\n"

expect > {send "username\r"}
expect "Enter" {send "password\r"}

expect ">"
send "$command\r"

But it got stuck before ? prompt : The "?" prompt used to type login in remeote system. but it got stuck at that point like that:

spawn telnet 172.26.34.100 2600
Trying...
Connected to 172.26.34.100.
Escape character is '^]'.


telnet> send brk
LOGIN

expect sends login before "?" or cannot sense "?"
any advice for this ??

Posted by admin (Graham Ellis), 3 March 2008
Why are you sending \r at some points and \n at others?  Are you sure you have those exactly right?   You know where it is sticking so that is the place to look at this in great detail!

Posted by xramm (xramm), 7 March 2008
on 03/03/08 at 19:08:33, Graham Ellis wrote:
Why are you sending \r at some points and \n at others?  Are you sure you have those exactly right?   You know where it is sticking so that is the place to look at this in great detail!


Another problem I faced that usage of expect_out
I want to parse all of result from remote computer output like this:

expect {
     -re "Number of nodes: (\[0-9\]*).*$" {
     set cikti $expect_out(buffer)
     exec echo "BCSMON '$cikti'" >> /tmp/bcsmon
   
        }

even though I setup match_max value to big numbers it gave only the little part of output...

is there any advice to get all output ?

Thanks

Posted by admin (Graham Ellis), 7 March 2008
If you use a wild card pattern match at the end of your regular expression (such as .*$), expect will match only up to the current point when it checks, so you'll probably only get a part of the output.  You should find your script to be more reliable if you match up to a specific end sequence such as a new line.   One of the other issues with expect is that the output buffer size is limited, and very often a loop of expects checking up to a new line can be much more effective than a single expect to the end sequence.

Posted by cwjolly (Bezoar), 11 April 2008
on 03/07/08 at 14:39:18, xramm wrote:
Another problem I faced that usage of expect_out
I want to parse all of result from remote computer output like this:

expect {
     -re "Number of nodes: (\[0-9\]*).*$" {
     set cikti $expect_out(buffer)
     exec echo "BCSMON '$cikti'" >> /tmp/bcsmon
   
        }

even though I setup match_max value to big numbers it gave only the little part of output...

is there any advice to get all output ?

Thanks


I agree with the previous poster that you should use \r when doing a send It is likely that that signals the terminal to flush the input buffer as most terminals are in line buffer mode.  Also you should not max out the match_max you should instead use the full_buffer target to buffer up your data.  See attached example.  Another thing,  in expect the ^ and $ refer to the beginning and end of the data that expect has just read in not the begining of a line and end of a line( which is traditional).  If you are going to parse data then you must look for unique delimiters (\n most often) or unique patterns that match ALL of your data. The regexp {[0-9]*.*$} says match on Zero or More Numbers followed by Zero or More of any Character until end of data. An empty string , a string with no numbers  and a String of all numbers would match.  As regexps go it is very bad.  In the excerpt below, I assume that  your are receiving several lines of  three numbers separated by whitespace. The expect script matches them and assignes the first number to a  and so forth the ()'s are groupings that can
be pulled out.   Naturally expect_out(buffer) = expect_out(0,string)
1 2 3
3 4 5
...
expect {
    ...
    -re  ([0-9]+)[ \t]+([0-9]+)[ \t]+([0-9]+)[ \t]+} {
          set a $expect_out(1,string);
            set b $expect_out(2,string);
            set c $expect_out(3,string);
            exp_continue;
       }

Example using full_buffer .
set my_id $spawn_id;
set bad 0;
set done 0;
exp_internal 0; # set to one for extensive debug
log_user 0; # set to one to watch action
set mybuffer ""
set timeout 30
expect {
   -i $my_id
   -re "$prompt" {
         append mybuffer $expect_out(buffer); # this will have prompt in it
         send "exit\r"
           exp_continue;
       }
   timeout {
        exec kill -9 $pid
        set bad 1
        exp_continue;
     }
   fullbuffer {
       append mybuffer $expect_out(buffer);  
       exp_continue;
     }
   eof {
          puts "Eof detected "
          set done 1 ;
     }
}
set exitstatus [ exp_wait -i $my_id ];
catch { exp_close -i $my_id };

process $mybuffer;


Hope this helps  Carl





This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho