SOLUTION: Keeping Telnet Session Open

From: Crist Clark (crist.clark@globalstar.com)
Date: Fri Jan 27 2006 - 19:11:25 EST


After more tinkering with my expect script, I seem to have found
what I need,

        expect -f - <<ExpectScript

        log_user 0
        if {[fork]!=0} {exit}
        disconnect
        spawn telnet host
        log_file -a logfile
        expect {
                -timeout -1
                eof exit
        }

        ExpectScript

Crist Clark wrote:
> 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}
> disconnect
> spawn telnet host
> wait
>
> ExpectScript
>
> 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@globalstar.com
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@globalstar.com
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers


This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:38:47 EDT