How to use Expect with SCP
Roger McCarrick
I need an expect script that can SCP to a list of hosts (contained in a
file) and copy over file(s).
I have a basic script working that already has the password as a variable
and the host and file is passed as arguments.
The script is then used in a bash script in a 'for' loop ..
------------------------
#!/usr/bin/expect
set host [lindex $argv 0]
set file [lindex $argv 1]
spawn scp $file roger@$host:$file
expect {
"Are you sure you want to continue connecting (yes/no)?"
send "yes\r"
}
expect "Password:"
send "ThisIsMyActualPassword\r"
interact
------------------------
and then stick this into a loop
------------------------
#!/bin/bash
for i in `cat hosts.list`
do
/home/now/scpup.ex $i fileName
done
------------------------
I have problems with this if I am asked if I want to save the secure key
"yes or no"
I have problems if there is a timeout in connecting
And of course a big problem is that my password is in the script.
I want the script to ask me my password once when I run the script and
then use it as it works it's way thru the list.
Dealing with the timeouts and "yes/no" is not top priority .. but if there
are suggestions I would appreciate them.
Oh and please don't reply if your answer is "see the documentation" I
always read documentation ... but I like to learn by example also .....
thanx
Roger McCarrick
rand mair fheal
celtic...@celticweb.com (Roger McCarrick) wrote:
> Hi
>
> I need an expect script that can SCP to a list of hosts (contained in a
> file) and copy over file(s).
this is part of my expect-scp script
#!/usr/local/bin/expect
set time_out 60
set host ...
set password ...
set foreignpath ...
set localpath ...
switch -- $operation {
get {
spawn scp root@$host:$foreignpath $localpath
expect {password: } {send "$password\r"; exp_continue} eof
}
put {
spawn scp $localpath root@$host:$foreignpath
expect {password: } {send "$password\r"; exp_continue} eof
}
}
exit 0
Cameron Laird
.
.
I strongly urge you to collapse bash out of the solution.
I believe you'll find the result more satisfying. Expect
can do everything bash does (modulo small user-interface
issues on which Larry Virden and I still occasionally
struggle), and more, particularly in regard to looping
over an "interior" operation.
Do you understand how to use a multi-way expect command
to branch, depending on whether or not the scp client
asks such questions as whether to save a key?
It's likely you'll find autoexpect <URL: http://
wiki.tcl.tk/autoexpect > convenient in scripting Expect.
If I understand you correctly, once you've made these and
related changes, there no longer will be an issue "that
[your] password is in the script." If I'm wrong about
this, come back, and we'll chat about that, specifically.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Roger McCarrick
Thanx
I will look at the site ....
yes u r correct .. I don't want the script to keep my password.
And I use the bash "for" loop .. cos that's just what I came up with at
the time .. it's is not at all required that I use it
thanx again
Roger
In article
<2EE5A19FBA140F47.77349E0A...@lp.airnews.net>,
Glenn Jackman
wrote:
>expect "Password:"
>send "ThisIsMyActualPassword\r"
For the password try:
proc getPassword {host} {
puts -nonewline "Password for $host: "
flush stdout
stty -echo
gets stdin password
stty echo
puts ""
return $password
}
expect "Password:"
send -- "[getPassword $host]\r"
>#!/bin/bash
>for i in `cat hosts.list`
>do
>/home/now/scpup.ex $i fileName
>done
As Cameron mentioned, use Tcl
set fid [open hosts.list r]
while {[gets $fid i] > 0} {
# your existing expect script body goes here
}
close $fid
>
>
>I have problems with this if I am asked if I want to save the secure key
>"yes or no"
>
>I have problems if there is a timeout in connecting
Investigate multi-pattern expect commands, the "default" pattern, and
the expect_before and exp_continue commands. For example:
# use expect_before before your first regular expect command
expect_before {
"save secure key (yes/no) {
send "something\r"
exp_continue
}
timeout {
puts "process timed out"
exit
}
}
--
Glenn Jackman
gle...@ncf.ca
Don Libes
Don
Roger McCarrick
Don Libes
will see the prompt and start typing and the terminal driver will ECHO
THE PASSWORD because stty -echo has yet to occur. Of course, users
generally aren't fast enough but one day someone will drive your
script with Expect and then you'll run into the problem for sure.
(This was a common problem on Linux where they made this mistake in
the getpass() implementation. Not sure if it's been fixed.)
Don
celtic...@celticweb.com (Roger McCarrick) writes:
> Yes please if u could
>
marsd
> the getpass() implementation. Not sure if it's been fixed.)
No. I had a script that behaved like this recently. Using expect for
su and I called it like:
expect ".*asswor.*" {
puts -nonewline stdout "Password: "
flush stdout
stty -echo, etc..
You could just see the password before interact kicked in.
Kernels 2.4.12 and 2.2.14.
> > > Call stty *before* prompting. Do I need to explain why?
I was wondering about this, thanks.
lvi...@yahoo.com
According to Cameron Laird <cla...@starbase.neosoft.com>:
: Expect
:can do everything bash does (modulo small user-interface
:issues on which Larry Virden and I still occasionally
:struggle),
I guess I would have said "Expect has many similar functions to bash" -
and the differences are not small to someone used to using bash -
from interactive, login shell features like command completion,
command line editing, etc. to programming capability such as
subprocess control, piping, special argument processing, etc.
I suspect I could, with some effort, identify a hundred or more differences
between bash-out-of-the-box and expect (or tcl)-out-of-the-box.
I certainly understand that Expect was never intended to be a login shell,
and so of course it doesn't come with all the features of one. I never thought
that it should.
I also understand that one could write a variety of procs to add to tcl
nearly equivalent functionality for many of these differences.
My thoughts on all of this spin off from my peculiar way of thinking - is
tcl merely a scripting language - or is it suitable for use as
a login shell ... and my conclusion that not only is tcl not now suitable,
but the amount of work to make it suitable would be
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting