Tcl - problem with expect, interact, and stdin

Author

problem with expect, interact, and stdin

Barry

2006-12-19, 7:14 pm

I'm trying to use expect to generalise remote command execution via a
number of protocols. Part of the requirement is for the system to
accept potentially large amounts of standard input (i.e. thousands of
lines of text).

I tried the following expect script (telnet1.expect):

set host yourhostnamehere
set user yourusernamehere
set pass yourpasswordhere

set timeout 10
set send_slow {1 .1}
set prompt "(%|'|\\\$) $"

eval spawn telnet $host
expect "login: "
send "$user\r"
expect "Password: "
send "$pass\r"
expect -re $prompt

send "cat - > /tmp/telnet1.out\r"
interact

and executed it via:
cat my40kbtextfile | expect telnet1.expect

However, either only part of the file is transmitted, or bits of the
file are missing on the remote host. The file is a clean ASCII text
file with no non-printable characters.

I've tried this on Redhat 7.3 Linux (gcc 2.96) and Solaris 2.8 sparc
(gcc 2.95.3), expect 5.4.3 built from source.

I've also tried using:

spawn ksh
expect -re $prompt
send "cat - > /tmp/telnet1.out\r"
interact

with the same result.

Finally, I tried replacing interact with:

set count 0
while {![eof stdin]} {
if {[gets stdin line] != -1} {
send "$line\r"
incr count
} else {
send_user "$count - blocked: [fblocked stdin], eof
[eof stdin]\n"
}
}

and I found that stdin is fblocked for a period that could potentially
account for the point(s) where interact drops out.

I've tried increasing buffer sizes with no effect. Can anyone suggest
how I may get interact to behave as expected?

TIA,
Barry

Cameron Laird

2006-12-20, 4:14 am

In article <1166545585.430186.46810@f1g2000cwa.googlegroups.com>,
Barry <turtlefaeces@hotmail.co.uk> wrote:
>I'm trying to use expect to generalise remote command execution via a
>number of protocols. Part of the requirement is for the system to
>accept potentially large amounts of standard input (i.e. thousands of
>lines of text).
>
>I tried the following expect script (telnet1.expect):
>
> set host yourhostnamehere
> set user yourusernamehere
> set pass yourpasswordhere
>
> set timeout 10
> set send_slow {1 .1}
> set prompt "(%|'|\\\$) $"
>
> eval spawn telnet $host
> expect "login: "
> send "$user\r"
> expect "Password: "
> send "$pass\r"
> expect -re $prompt
>
> send "cat - > /tmp/telnet1.out\r"
> interact
>
>and executed it via:
> cat my40kbtextfile | expect telnet1.expect
>
>However, either only part of the file is transmitted, or bits of the
>file are missing on the remote host. The file is a clean ASCII text
>file with no non-printable characters.
>
>I've tried this on Redhat 7.3 Linux (gcc 2.96) and Solaris 2.8 sparc
>(gcc 2.95.3), expect 5.4.3 built from source.
>
>I've also tried using:
>
> spawn ksh
> expect -re $prompt
> send "cat - > /tmp/telnet1.out\r"
> interact
>
>with the same result.
>
>Finally, I tried replacing interact with:
>
> set count 0
> while {![eof stdin]} {
> if {[gets stdin line] != -1} {
> send "$line\r"
> incr count
> } else {
> send_user "$count - blocked: [fblocked stdin], eof
>[eof stdin]\n"
> }
> }
>
>and I found that stdin is fblocked for a period that could potentially
>account for the point(s) where interact drops out.
>
>I've tried increasing buffer sizes with no effect. Can anyone suggest
>how I may get interact to behave as expected?

Barry

2006-12-20, 8:12 am

Hi,

thanks for your reply.

The end requirement is to be able to execute an arbitrary shell
command, or sequence of arbitrary shell commands, on a remote host, and
potentially feed the command(s) with data on standard input, read the
command's output (ideally with standard error separate from standard
input, but we can cope if not), and obtain the exit code of the command
sequence. In effect, we want to be able to run any command on a remote
host and treat it like we are running it locally.

Currently we do this via a wrapper that uses rsh, but we want the
flexibility to be able to use other protocols to obtain the remote
shell, such as rlogin, rexec, telnet, ssh-with-keys, ssh-with-password.
The idea is to automate the login with expect and have it hand over the
shell to execute the command sequence and terminate.

Shell command sequences could be pretty much anything, that's up to the
higher level applications, but typical examples might be:

a) transfer a script and execute it on the remote host, capturing the
output:
result="`cat myscript | protocolwrapper $host 'cat - >
/tmp/myscript; sh -c /tmp/myscript ...'`"

b) get contents of a file from the remote host:
protocolwrapper $host 'cat /etc/configfile'

c) test for existence of a file
protocolwrapper $host '[ -f /etc/configfile ]'
rc=$?

I realise that there are better ways to transfer files and execute them
when the tasks are treated separately, but we don't have that luxury -
the work has to continue to be done via a wrapper command of the form:
protocolwrapper <host> <command>.

Thanks,
Barry

Cameron Laird

2006-12-20, 7:08 pm

In article <1166611021.499596.57680@f1g2000cwa.googlegroups.com>,
Barry <turtlefaeces@hotmail.co.uk> wrote:
>Hi,
>
>thanks for your reply.
>
>The end requirement is to be able to execute an arbitrary shell
>command, or sequence of arbitrary shell commands, on a remote host, and
>potentially feed the command(s) with data on standard input, read the
>command's output (ideally with standard error separate from standard
>input, but we can cope if not), and obtain the exit code of the command
>sequence. In effect, we want to be able to run any command on a remote
>host and treat it like we are running it locally.
>
>Currently we do this via a wrapper that uses rsh, but we want the
>flexibility to be able to use other protocols to obtain the remote
>shell, such as rlogin, rexec, telnet, ssh-with-keys, ssh-with-password.
>The idea is to automate the login with expect and have it hand over the
>shell to execute the command sequence and terminate.
>
>Shell command sequences could be pretty much anything, that's up to the
>higher level applications, but typical examples might be:
>
>a) transfer a script and execute it on the remote host, capturing the
>output:
> result="`cat myscript | protocolwrapper $host 'cat - >
>/tmp/myscript; sh -c /tmp/myscript ...'`"
>
>b) get contents of a file from the remote host:
> protocolwrapper $host 'cat /etc/configfile'
>
>c) test for existence of a file
> protocolwrapper $host '[ -f /etc/configfile ]'
> rc=$?
>
>I realise that there are better ways to transfer files and execute them
>when the tasks are treated separately, but we don't have that luxury -
>the work has to continue to be done via a wrapper command of the form:
> protocolwrapper <host> <command>.

Barry

2006-12-21, 4:11 am

I see your points. I think I need to go back to the drawing board a bit
on this one.
Thanks for your input,
Barry

Sponsored Links