Re: expect.pm problem

Whew. This is rather a difficult mess to attack. Find out if the text editor you are using to write programs has any sort of facility for doing auto-indentation, so that it's easy to make sure that blocks of code are properly indented. If your current editor doesn't support this, look for an editor that does.

I don't actually have Expect.pm installed on my machine at the momemnt, but even if I did, I'd have no way to test your code for myself. Still, after editing a copy of it to apply proper indentation, the following points became evident:

You need to include "use strict" and "use warnings"
You don't seem to understand the "open" and "close" calls. The first argument to open() should either be the name you want to assign to a filehandle, in CAPS (e.g. SPCMAP, not spcmap), or else it should be a scalar variable with lexical scope: open my $spcmap, '<', $mapfile or die ... Then, the close() call needs to be given the FILEHANDLE (i.e. first arg given to open()) -- not the name of the file that was opened.
You don't seem to understand quantifiers and/or the "\b" operator in regular expressions; in your regex: /\b*error1\b*/ the "*" quantifier makes no sense when applied to the "zero-width word-boundary assertion".
Inside your while(1) loop, you read a command from STDIN, and you do one of three things depending on its content: the first thing is exit the loop if "quit " occurs anywhere in the string (no problem there); the second involves some other checks and mods -- including chomp $cmd; and the third involves just passing $cmd to expect->send() -- without chomping it. I wonder if that might be part of the problem (I really don't know.)

Apart from that, I have no way of knowing what might be wrong. But you may want to see whether IPC::Open2 or IPC::Open3 could do what needs to be done -- they are part of the core distribution, and may be simpler to use than Expect.

update: one other point of confusion -- you have those two "nusmv_*" subroutines defined at the bottom of the code, but the calls to these subroutines are commented out. I suppose this is an intentional part of you debugging efforts, but if skipping those calls is part of the problem, you're the only one who can figure that out (not us); if skipping the calls has no effect on the program's behavior, why include them in the post?

Comment on Re: expect.pm problem Select or Download Code

Replies are listed 'Best First'.
Re^2: expect.pm problem by AT (Initiate) on Jul 14, 2005 at 16:16 UTC
Sorry for the en-masse violation of writing ethics! I was trying to give a smaller portion from the main code and so it became messy. All suggestions accepted and implemented. Here is what I figured out but which hasnt helped me solve it: Looking at the debug code, the problem occurs when the called program (NuSMV) is taking longer time ~0.3 seconds to give the result. Somehow spurious or extra input (i.e. NuSMV prompts, 'NuSMV >') are coming back to expect in the meanwhile, and accepting that, it moves on. I cant figure out why this is happening. If it takes less time ~0.0 secs (NuSMV gives a timer), there is no problem. Regd Open: I tried some stuff but not clear on the std I/O operations. here is the problem. A accepts input from user, passes that input to B (A' stdout -> B's stdin?), B processes, gives the result back (B's stdout -> A's stdin?), A displays the result back (A' stdout -> monitor). (Who's the reader, who is the writer? ) I suppose this should be rather straightforward for pipe gurus ;-) - can you suggest code on this. thanks, AT	[reply]

Replies are listed 'Best First'.

Re^2: expect.pm problem
by AT (Initiate) on Jul 14, 2005 at 16:16 UTC

Regd Open: I tried some stuff but not clear on the std I/O operations. here is the problem. A accepts input from user, passes that input to B (A' stdout -> B's stdin?), B processes, gives the result back (B's stdout -> A's stdin?), A displays the result back (A' stdout -> monitor). (Who's the reader, who is the writer? )
I suppose this should be rather straightforward for pipe gurus ;-) - can you suggest code on this.

thanks, AT

[reply]