send: spawn id exp6 not open while executing

[alapa...@gmail.com]

#!/usr/bin/expect

# .....- configuration .....- #
set device [lrange $argv 0 0]
set user [lrange $argv 1 1]
set pass [lrange $argv 2 2]
set enpass [lrange $argv 3 3]
set timeout 60
set now [clock seconds]
set date [clock format $now -format {%b-%d-%Y}]

# ..... do not edit below ..... #
spawn ssh -o StrictHostKeyChecking=no $user@$device
expect "password:"
send "$pass\n"
send "\n"
expect ">"
send "en\n"
expect "Password:"
send "$enpass\n"
expect "#"
#log_file $device/$device.txt
log_file /var/lib/tftpboot/$device/$device-$date.txt
send "term len 0\n"
send "show running-config\n"
expect "end\r"
send "\n"
send "exit\n"
log_file


Error is below mentioned !!!

send: spawn id exp6 not open
while executing
"send "term len 0\n""
(file "/usr/local/sbin/qbackup1" line 24)

[alapa...@gmail.com]

please help on any one !!!!! urgent basics

[Andreas Leitgeb]

alapa...@gmail.com <alapa...@gmail.com> wrote:
> On Tuesday, January 3, 2017 at 4:04:54 AM UTC+5:30, alapa...@gmail.com wrote:
>> spawn ssh -o StrictHostKeyChecking=no $user@$device
>> expect "password:"
>> send "$pass\n"
>> send "\n"
>> expect ">"
>> send "en\n"
>> expect "Password:"
>> send "$enpass\n"
>> expect "#"

>> log_file /var/lib/tftpboot/$device/$device-$date.txt
>> send "term len 0\n"
>>

>> Error is below mentioned !!!
>>
>> send: spawn id exp6 not open
>> while executing
>> "send "term len 0\n""
>> (file "/usr/local/sbin/qbackup1" line 24)
> please help on any one !!!!! urgent basics

I'd guess that the ssh command already died away, when this error arrives.

Is there a noticeable delay between starting the script and this error
occurring, or does it fail "instantly"?

Maybe the target's output differs a bit from what you expect.

Maybe you need to pass little delays before sending data. The target
might flush its input right *after* writing the prompt, so if you
immediately write after seeing the prompt, your data might be lost.

Does the log file contain anything interesting?

[Uwe Klein]

ejaculatio praecox :-)

my guess is that the other side sends "password: " ( note the space
after ':' )
password is sent before the recipient is ready.
The passoword string is ignored or only partly received.

then there is no error handling.
Any fall through from a timeout behaves
like a success receiving the expected string.

Uwe