Re: Using expect.pm in background process

Have you tried using the Net::Telnet module? It is almost always better (not to mention more portable) to use the Net::* modules to access network services than to try and control external programs.

However even if you do need to control an external program, I have found Net::Telnet to be more reliable than Expect.pm anyway (just connect to localhost and go from there). I'm not entirely sure why Expect.pm was failing in background processes, but I am using Net::Telnet in the background at the moment (on Tru64 UNIX) with no problems.

Comment on Re: Using expect.pm in background process

Replies are listed 'Best First'.
Re: Re: Using expect.pm in background process by fsn (Friar) on Sep 28, 2002 at 09:56 UTC
I think you dismiss the Expect modules to early. While Net::Telnet certainly has an impressive featureset, with even patternmatching and timeouts, Expect is even better. In my work as a Test Engineer I found Expect and Expect.pm to be easy to work with. According to the documentation, Expect should work on "any modern POSIX Unix", and under Cygwin (but not ActivePerl), which also makes it rather portable. However, if the brother doesn't need all the bells and whistles of Expect, your suggestion is an excellent one.	[reply]
Re: Re: Re: Using expect.pm in background process by jj808 (Hermit) on Sep 28, 2002 at 14:28 UTC
I guess it's a case of 'once bitten, twice shy'... When I was using Expect to control an interactive command process, it occasionally got out of sync - I would send a command, get a truncated response, send another command and get the previous response in full. This was not a timeout or prompt-matching issue. But since replacing Expect with Net::Telnet I have had no problems (famous last words!). Maybe it didn't like ~~DEC~~ ~~Compaq~~ HP Tru64 UNIX or DEC AlphaServer hardware? JJ	[reply]


No such thing as a small change
	PerlMonks