From: Schubert on
On Feb 13, 11:32 pm, Icarus Sparry <use...(a)icarus.freeuk.com> wrote:
> On Tue, 13 Feb 2007 18:25:50 -0800, Schubert wrote:
> > My mission is very simple.
>
> > 1. Login in a server through ssh.
> > 2. Then run a batch file.
>
> > I use Expect to do the automation.
>
> > The script is like this:
> > --------------------------------------------------------------------------
> > spawn ssh -p 10022 root@<Server IP address>
>
> > expect "root@<Server IP address>'s password: "
> > send "public\r"
>
> > expect {
> > "\[root@<Server Name>:<Server IP address>\]" {
> > send "run batch filename.txt\r"}
>
> > }
>
> > --------------------------------------------------------------------------
>
> > Here is the screen output I got if I do this manually:
> > ------------------------------------------------------------------------
>
> >> ssh -p 10022 root@<Server IP address>
>
> > root@<Server IP address>'s password: public <key-in>
>
> > <Server Name>
> > You're logged on from <Another Server IP address>
>
> > [root@<Server Name>:<Server IP address>]: run batch filename.txt
> > <key-
> > in>
> > batch file success message shown
> > -------------------------------------------------------------------------
> > But when I use Expect script above to automate the manual steps, it
> > will get stuck running the batch file. It simply shows the
> > [root@<Server Name>: <Server IP address>] prompt and then stops. Does
> > anybody know why this happens? Greatly appreciated.
>
> Your first problem is that the '[' character means two different things to
> expect. The first meaning command substitution, and the second is in
> pattern matching. You have only one layer of protection against these two
> meanings, so you avoid the command substitution, but not the "glob"
> meaning.
>
> In general with tcl it is better to use the {} rather than the "" way of
> quoting.
>
> Expect has a "-exact" flag to its expect command. So you should write this
> as
>
> expect {
> -exact {[root@<ZServer Name>:<Server IP Address>]} {
> send "run batch filename.txt\r" }
>
> }
>
> However doing this will not solve your problem. There are two things you
> can obviously do to help.The problem is almost certainly in the pattern
> match. It may be that the remote server is sending extra characters
> perhaps to make the prompt appear in a different colour.
>
> The first thing is to run "expect -d yourscript". This will produce lots
> of output where you will see expect asking itself 'does "some output or
> other" match exact pattern "[root@...]" - no'. In this you will see what
> expect has received, and you may be able to alter your pattern to account
> for any extra characters.
>
> The other thing you can do is to find the "autoexpect" script, which comes
> with expect. Run this once, doing the commands you want, and it will write
> the expect script for you.- Hide quoted text -
>
> - Show quoted text -

Hi Lcarus, I have tried your way, but got a very wierd problem, let me
first attach the script (generated by autoexpect) afterwards, then
explain what i have seen:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
#!/usr/lab/bin/expect -f

set force_conservative 0 ;# set to 1 to force conservative mode even
if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}

set timeout -1
spawn ssh -p 10022 root@<Server IP address>
match_max 100000
expect -exact "root@<Server IP address>'s password: "
send -- "public\r"
expect -exact "\r
\r
\r
EMS CLI\r
You're logged on from <another server IP address> \r\r
\r
\r
\[root(a)emscli:<another server IP address>\] "
send -- "run batch filename.txt\r"
expect -exact "run batch filename.txt\r
\[root(a)emscli:<another server IP address>\] "
send -- "exit\r"
expect eof
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
It runs well until the prompt [root(a)emscli:<another server IP
address>] appears, however, it is covered with two "run batch
filename.txt" command. In other words, I can see part of the prompt
from the space between the command "run batch filename.txt". Isn't
that wierd??? Then, it stops, no any response even if I press carriage
return. Anybody can figure it out???

From: Steven Mocking on
Schubert wrote:
> On Feb 14, 5:24 am, Alexander Skwar <alexan...(a)skwar.name> wrote:
>> Schubert <cxbest2...(a)yahoo.com>:
>>
>>> My mission is very simple.
>>> 1. Login in a server through ssh.
>>> 2. Then run a batch file.
>>> I use Expect to do the automation.
>> Hm - why are you using Expect to do the automation? I'd suggest
>> to setup public key authentication. If that's setup, you could
>> do
>>
>> ssh $host $command
>>
>> Ie. login to $host and then run $command. No need for expect.
>>
>> Alexander Skwar
>
> Thanks Alexander, but this is just a very small part of the entire
> mission. Do you know what the problem is?

Disclaimer: the gender of the fictional persona is entirely coincidental

Alice: I'm using a gun to shoot my windows open, but I seem to be
shooting holes in the wall instead. I think it's broken.
Bob: Use the window's handle
Alice: You don't understand. How will that make my gun work?
From: Schubert on
On Feb 14, 10:39 am, Steven Mocking
<u...(a)quicknet.youmightwanttogetridofthis.nl> wrote:
> Schubert wrote:
> > On Feb 14, 5:24 am, Alexander Skwar <alexan...(a)skwar.name> wrote:
> >> Schubert <cxbest2...(a)yahoo.com>:
>
> >>> My mission is very simple.
> >>> 1. Login in a server through ssh.
> >>> 2. Then run a batch file.
> >>> I use Expect to do the automation.
> >> Hm - why are you using Expect to do the automation? I'd suggest
> >> to setup public key authentication. If that's setup, you could
> >> do
>
> >> ssh $host $command
>
> >> Ie. login to $host and then run $command. No need for expect.
>
> >> Alexander Skwar
>
> > Thanks Alexander, but this is just a very small part of the entire
> > mission. Do you know what the problem is?
>
> Disclaimer: the gender of the fictional persona is entirely coincidental
>
> Alice: I'm using a gun to shoot my windows open, but I seem to be
> shooting holes in the wall instead. I think it's broken.
> Bob: Use the window's handle
> Alice: You don't understand. How will that make my gun work?- Hide quoted text -
>
> - Show quoted text -

Well, Steven, I totally understand what you mean, but there will be
hundreds of machines that require me to do this (ssh in a server and
then run batch) daily. Do you still think that's an easy job if I
don't automate them???

From: Schubert on
On Feb 14, 11:02 am, Icarus Sparry <use...(a)icarus.freeuk.com> wrote:
> On Wed, 14 Feb 2007 06:48:10 -0800, Schubert wrote:
> > On Feb 13, 11:32 pm, Icarus Sparry <use...(a)icarus.freeuk.com> wrote:
> >> On Tue, 13 Feb 2007 18:25:50 -0800, Schubert wrote:
> >> > My mission is very simple.
>
> >> > 1. Login in a server through ssh.
> >> > 2. Then run a batch file.
>
> >> > I use Expect to do the automation.
>
> >> > The script is like this:
>
> -------------------------------------------------------------------------->> > spawn ssh -p 10022 root@<Server IP address>
>
> >> > expect "root@<Server IP address>'s password: "
> >> > send "public\r"
>
> >> > expect {
> >> > "\[root@<Server Name>:<Server IP address>\]" {
> >> > send "run batch filename.txt\r"}
>
> >> > }
>
> --------------------------------------------------------------------------
>
> >> > Here is the screen output I got if I do this manually:
>
> ------------------------------------------------------------------------
>
> >> >> ssh -p 10022 root@<Server IP address>
>
> >> > root@<Server IP address>'s password: public <key-in>
>
> >> > <Server Name>
> >> > You're logged on from <Another Server IP address>
>
> >> > [root@<Server Name>:<Server IP address>]: run batch filename.txt
> >> > <key-
> >> > in>
> >> > batch file success message shown
>
> -------------------------------------------------------------------------
>
>
>
> >> > But when I use Expect script above to automate the manual steps, it
> >> > will get stuck running the batch file. It simply shows the
> >> > [root@<Server Name>: <Server IP address>] prompt and then stops. Does
> >> > anybody know why this happens? Greatly appreciated.
>
> >> Your first problem is that the '[' character means two different things
> to
> >> expect. The first meaning command substitution, and the second is in
> >> pattern matching. You have only one layer of protection against these two
> >> meanings, so you avoid the command substitution, but not the "glob"
> >> meaning.
>
> >> In general with tcl it is better to use the {} rather than the "" way of
> >> quoting.
>
> >> Expect has a "-exact" flag to its expect command. So you should write
> this
> >> as
>
> >> expect {
> >> -exact {[root@<ZServer Name>:<Server IP Address>]} {
> >> send "run batch filename.txt\r" }
>
> >> }
>
> >> However doing this will not solve your problem. There are two things you
> >> can obviously do to help.The problem is almost certainly in the pattern
> >> match. It may be that the remote server is sending extra characters
> >> perhaps to make the prompt appear in a different colour.
>
> >> The first thing is to run "expect -d yourscript". This will produce lots
> >> of output where you will see expect asking itself 'does "some output or
> >> other" match exact pattern "[root@...]" - no'. In this you will see what
> >> expect has received, and you may be able to alter your pattern to account
> >> for any extra characters.
>
> >> The other thing you can do is to find the "autoexpect" script, which
> comes
> >> with expect. Run this once, doing the commands you want, and it will
> write
> >> the expect script for you.- Hide quoted text -
>
> >> - Show quoted text -
>
> > Hi Lcarus, I have tried your way, but got a very wierd problem, let me
> > first attach the script (generated by autoexpect) afterwards, then
> > explain what i have seen:
>
> ---------------------------------------------------------------------------­---------------------------------------------------------------------------­-----------------------------------------------------
>
>
>
> > #!/usr/lab/bin/expect -f
>
> > set force_conservative 0 ;# set to 1 to force conservative mode even
> > if
> > ;# script wasn't run conservatively originally
> > if {$force_conservative} {
> > set send_slow {1 .1}
> > proc send {ignore arg} {
> > sleep .1
> > exp_send -s -- $arg
> > }
> > }
>
> > set timeout -1
> > spawn ssh -p 10022 root@<Server IP address>
> > match_max 100000
> > expect -exact "root@<Server IP address>'s password: "
> > send -- "public\r"
> > expect -exact "\r
> > \r
> > \r
> > EMS CLI\r
> > You're logged on from <another server IP address> \r\r
> > \r
> > \r
> > \[root(a)emscli:<another server IP address>\] "
> > send -- "run batch filename.txt\r"
> > expect -exact "run batch filename.txt\r
> > \[root(a)emscli:<another server IP address>\] "
> > send -- "exit\r"
> > expect eof
>
> ---------------------------------------------------------------------------­---------------------------------------------------------------------------­-----------------------------------------
>
> > It runs well until the prompt [root(a)emscli:<another server IP
> > address>] appears, however, it is covered with two "run batch
> > filename.txt" command. In other words, I can see part of the prompt
> > from the space between the command "run batch filename.txt". Isn't
> > that wierd??? Then, it stops, no any response even if I press carriage
> > return. Anybody can figure it out???
>
> The "stop" is because it is still looking for the pattern. there is nothing
> in your script that is expecting you to press CR, so this is just buffered.
>
> the doubled "run batch..." is not weird, it is the result of echoing the
> command and it thinking that it has matched the command.
>
> Try changing the
>
> expect -exact "run batch filename.txt\r
> \[root(a)emscli:<another server IP address>\] "
>
> to
>
> expect -exact "\[root(a)emscli:<another server IP address>\] "
>
> if this works then try this
>
> #!/usr/lab/bin/expect -f
> set force_conservative 0 ;# set to 1 to force conservative mode even if
> ;# script wasn't run conservatively originally
> if {$force_conservative} {
> set send_slow {1 .1}
> proc send {ignore arg} {
> sleep .1
> exp_send -s -- $arg
> }
>
> }
>
> proc prompt {} {
> global spawn_id
> expect -exact "\[root(a)emscli:<another server IP address>\] "
>
> }
>
> set timeout -1
> spawn ssh -p 10022 root@<Server IP address>
> match_max 100
> expect -exact "root@<Server IP address>'s password: "
> send -- "public\r"
> prompt
> send -- "run batch filename.txt\r"
> prompt
> send -- "exit\r"
> expect eof
>
> or send me the output of running 'expect -d', this email address is valid..- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

I still got the same problem when I execute the adapted script. I have
sent an email to you, Lcarus. Thank you.

From: Chris F.A. Johnson on
On 2007-02-14, Schubert wrote:
> On Feb 14, 10:39 am, Steven Mocking
>>
>> Alice: I'm using a gun to shoot my windows open, but I seem to be
>> shooting holes in the wall instead. I think it's broken.
>> Bob: Use the window's handle
>> Alice: You don't understand. How will that make my gun work?- Hide quoted text -
>>
>> - Show quoted text -
>
> Well, Steven, I totally understand what you mean, but there will be
> hundreds of machines that require me to do this (ssh in a server and
> then run batch) daily. Do you still think that's an easy job if I
> don't automate them???

Of course you automate them. Just don't use expect. Use host key
authentication and a shell script.


--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence