Re: Interactive Expect from bash Script
Esben Stien writes: > # _run=`/usr/bin/expect<<'EOF' > /usr/bin/expect<<'EOF' > set passwd $env(_passwd) > set usr $env(_usr) > set host $env(_host) You never set these variables. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Interactive Expect from bash Script
Andreas Schwab writes: > Esben Stien writes: >> set passwd $env(_passwd) >> set usr $env(_usr) >> set host $env(_host) > You never set these variables. Right, sorry, I had them in my environment. I've set them now, but it doesn't make any difference. -- Esben Stien is b0ef@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n
Re: Interactive Expect from bash Script
Mike Frysinger writes:
> you could accomplish all of this with python alone. are you aware of
> the pexepct module ? http://pexpect.sourceforge.net/
The implementation below is in python using pexepect and it works
fine. It still doesn't answer the question why this doesn't work in bash?
> if you're still set on this amalgamation, then might i suggest looking
> into the expect-lite package ? http://expect-lite.sourceforge.net/
expect-lite is still expect, so why do you recommend using this instead
of what I'm using now?
The following is the code in python:
#!/usr/bin/env python
import pexpect
import struct, fcntl, os, sys, signal
import urlparse
def sigwinch_passthrough (sig, data):
# Check for buggy platforms (see pexpect.setwinsize()).
if 'TIOCGWINSZ' in dir(termios):
TIOCGWINSZ = termios.TIOCGWINSZ
else:
TIOCGWINSZ = 1074295912 # assume
s = struct.pack ("", 0, 0, 0, 0)
a = struct.unpack ('', fcntl.ioctl(sys.stdout.fileno(), TIOCGWINSZ , s))
global global_pexpect_instance
global_pexpect_instance.setwinsize(a[0],a[1])
url = urlparse.urlparse(sys.argv[1]);
ssh_newkey = 'Are you sure you want to continue connecting'
p=pexpect.spawn('ssh'+' '+url.username+':'+url.password+'@'+url.hostname)
i=p.expect([ssh_newkey,'password:',pexpect.EOF,pexpect.TIMEOUT],1)
if i==0:
print "I say yes"
p.sendline('yes')
i=p.expect([ssh_newkey,'password:',pexpect.EOF])
if i==1:
#print "I give password",
p.sendline(url.password)
elif i==2:
print "I either got key or connection timeout"
pass
elif i==3: #timeout
pass
p.sendline("\r")
global global_pexpect_instance
global_pexpect_instance = p
signal.signal(signal.SIGWINCH, sigwinch_passthrough)
try:
p.interact()
sys.exit(0)
except:
sys.exit(1)
--
Esben Stien is b0ef@e s a
http://www. s tn m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@n n
Re: Interactive Expect from bash Script
Esben Stien writes: > The expect code works fine when executed outside the bash script, Please define "outside the bash script". Since you are passing the expect script on stdin the interact command will immediately read EOF, and expect will run into its implicit timeout. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Interactive Expect from bash Script
Andreas Schwab writes:
> Please define "outside the bash script".
If I run this, it works:
#!/usr/bin/expect
set passwd [lindex $argv 1]
set password passwd
spawn /usr/bin/ssh [lindex $argv 0]@[lindex $argv 2]
expect {
-re ".*Are.*.*yes.*no.*" {
send "yes\n"
exp_continue
#look for the password prompt
}
"*?assword:*" {
send $passwd
send "\n"
interact
#The expect command will now return
}
}
> Since you are passing the expect script on stdin the interact command
> will immediately read EOF, and expect will run into its implicit
> timeout.
Hmm, I see, so how am I supposed to run it?;)
--
Esben Stien is b0ef@e s a
http://www. s tn m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@n n
Re: Interactive Expect from bash Script
Esben Stien wrote: > export _csv=`python <<'END' As you have already discovered this is the source of your problem. > /usr/bin/expect<<'EOF' Times two, nested. The bash documentation says: Here Documents This type of redirection instructs the shell to read input from the current source until a line containing only delimiter (with no trailing blanks) is seen. All of the lines read up to that point are then used as the standard input for a command. Since you are using stdin for the here-document then the file descriptor associated with it will return EOF since it will already have read to the end of the file. > spawn /usr/bin/ssh $usr@$host The above will then always get EOF from the here-document file which has already been read to the end of file. This type of question is really better placed in the help-bash mailing list rather than the bug-bash mailing list. The help-bash list is relatively new and so we are always reminding people to use it when appropriate. Bob
Re: Interactive Expect from bash Script
Esben Stien writes: > Hmm, I see, so how am I supposed to run it?;) As above. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Interactive Expect from bash Script
Bob Proulx writes: >> spawn /usr/bin/ssh $usr@$host > > The above will then always get EOF from the here-document file which > has already been read to the end of file. Wrong. The spawned process is connected to the expect process via a pty, and will read whatever the latter sends to it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Interactive Expect from bash Script
Esben Stien wrote:
> If I run this, it works:
>
> #!/usr/bin/expect
Sounds good. Is there anything particular bad about running it as an
expect script? (Or in native python using pexepect? Or in native perl
using Perl's expect library? Or Ruby's?)
> Andreas Schwab writes:
> > Since you are passing the expect script on stdin the interact command
> > will immediately read EOF, and expect will run into its implicit
> > timeout.
>
> Hmm, I see, so how am I supposed to run it?;)
Personally I would use "#!/use/bin/env expect" and be done with it.
But if you really want to call it then the first easy way is to create
a script that does the expect portion just by itself. This is very
common such as often seen with 'sed' scripts called like:
#!/bin/sh
sed -f sedscript infile > outfile
But if you want the expect script to be contained within the shell
script then you need to write it out from the shell script first.
Then clean up the script. Which means things get more complicated due
to the need for trap handling and temporary file cleanup. Which is
why the use of expect directly seems best to me.
But if you really want to know then the following should do it. Note
that I didn't test it. There may be some detail still broken.
Note that with #!/bin/bash using trap on EXIT is sufficient. To use
this with a #!/bin/sh script one must also trap properly on every
other signal that might happen, usually HUP, INT, QUIT, TERM, and
perhaps PIPE though PIPE is definitely subtle and special. It is
rather of a mess. Bash is definitely better in this regard.
Bob
#!/bin/bash
unset tmpfile
cleanup() {
test -n "$tmpfile" && rm -f "$tmpfile"
}
trap "cleanup" EXIT
tmpfile=$(mktemp) || exit 1
cat >"$tmpfile" <<'EOF'
set passwd $env(_passwd)
set usr $env(_usr)
set host $env(_host)
spawn /usr/bin/ssh $usr@$host
expect {
-re ".*Are.*.*yes.*no.*" {
send "yes\n"
exp_continue
#look for the password prompt
}
"*?assword:*" {
send $passwd
send "\n"
interact
#The expect command will now return
}
}
EOF
env _passwd=foo _usr=foo _host=foo expect "$tmpfile"
Re: Interactive Expect from bash Script
Bob Proulx writes: > #!/bin/bash expect -c '...' "$_usr" "$_host" "$_passwd" RTFM? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Interactive Expect from bash Script
Andreas Schwab wrote: > Bob Proulx writes: > > > #!/bin/bash > expect -c '...' "$_usr" "$_host" "$_passwd" Of course that works too. Why were you so late to share this wisdom? > RTFM? It has probably been more than fifteen years since I have done any significant work with expect. And in the latter part I always used the perl library. Sometimes I want to help people and will suggest what I know but am lacking the infinite time and resources needed to know everything. I still believe sharing what I can is better than to keep useful information private. If nothing else it will annoy those who do to contribute something better. Bob
