UPDATE: Keeping Telnet Session Open

Thanks to several people for responding. Most suggestions have been
"expect" or "script." I'm not sure how script would help. How do I
even tell script what commands to run in a non-interactive, batch
environment? Since I never got past that, I couldn't test if it would
hold the connection open.

OTOH, expect is probably just the right tool for this. And go figure,
we already have it installed on the machine. Silly me for not thinking
of that. However, I'm rather the expect script novice (I'll build and
install it and all its dependencies for the developers, but heck if
I can use it). Perhaps some of the expect experts out there could
indulge me with what I am missing here? This is what I'll drop in for
the telnet command and am trying to do with expect,

expect -f - <<ExpectScript

log_file logfile
log_user 0
if {[fork]!=0} {exit}
spawn telnet host


Now, as far as I can tell, this almost works the way I want. I can
see the telnet running in the ps(1) output. I know that the server at
the other end is accepting the connection. The problem is that the
data passed over the telnet connection is not being written to logfile.
I must be missing something that any half-clued expect user would know.
Be gentle. It's my first expect script. (One little thing, whether I
have the "log_user" line there or not, no logfile. I have the log_user
there to keep "spawn telnet host" from being echoed back.)

Crist Clark wrote:
> Porting some scripts over from HPUX. This one seems to depend on some
> interesting behavior from the HP telnet. It does something like,
> telnet host > logfile &
> And the idea is that this process just sits in the background writing
> output from "host" to the log file.
> This doesn't work on Solaris (we're using 9). The Solaris telnet, when
> backgrounded in this manner, will immediately tell the other end it's
> done (you can watch the TCP FIN go out right away), and things close
> right up.
> Yes, this doesn't work for a reason. Telnet is a tool for _interactive_
> sessions. But before I makes some heads explode by telling them to import
> non-Sun software (netcat) or write this all in Perl or something else
> that can handle the TCP connectivity natively, does anyone have a way
> to trick the telnet into keeping the connection open? I tried something
> like,
> mkfifo -m 600 /tmp/.dumfifo
> telnet host < /tmp/.dumfifo > logfile &
> Hoping that the telnet would stay alive waiting for input on the FIFO,
> but it doesn't even start until it gets something pushed down the pipe
> and then quits. Maybe I'm missing some variant on that which could help?

Crist J. Clark crist.clark@xxxxxxxxxxxxxx
Globalstar Communications (408) 933-4387

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this e-mail in error, please contact postmaster@xxxxxxxxxxxxxx
sunmanagers mailing list