Re: pattern detection inside until loop in perl

Your code does appear to do what you are asking for so I find your question a bit confusing. However some simplifications are possible to make things more clear.

You have 2 ways to exit the loop:

- until ("" ne $gotit)
- if($gotit){last;}
[download]

I would simplify to one condition. Note null string is "false". Also $gotit doesn't appear to be necessary because it appears that the lookfor() method is looking for what you told it to with the are_match() method.

$PortObj->are_match("abcd"); # Pattern to match
send_prompt();  #I presume this happens?

while (!$PortObj->lookfor()  )
{
   print("Pattern is not detected\n");
   send_prompt();  #re-prompt
}

# pattern is detected here ... we continue
[download]

unless and until can sometimes confuse folks, so I tend to prefer using "while" for the vast majority of my loops like this.

Comment on Re: pattern detection inside until loop in perl Select or Download Code

Replies are listed 'Best First'.
Re^2: pattern detection inside until loop in perl by vrushali (Initiate) on Dec 16, 2010 at 13:22 UTC
Thank u for your response, it helped me a lot. Can you please tell me any other method apart from the lookfor method for pattern detection in streaming data coming from the serial port.	[reply]
Re^3: pattern detection inside until loop in perl by Marshall (Canon) on Dec 19, 2010 at 06:09 UTC
Communicating 2-way over a serial port in a simple, reliable way is actually a lot more complicated than it sounds! The crux of the matter is that there is no "end-to-end" protocol like TCP/IP. This is low level. You send out bytes. You listen for bytes. There is no guarantee that what you sent is what was received. In either direction it is possible that characters are deleted, inserted or transposed into other characters - this is due to how the hardware works. You don't send "messages" and listen for "messages". You have to deal with streams of raw characters sent and received. For sending, perhaps you send the string: "CMD=save\n" and that gets received as: "CMD=sav@#". If the listener is waiting for "\n", to signal the "end of incoming message", then there is going to be a problem! Probably you have to resend: "CMD=save\n" due to no response within some time out period. The listener maybe then sees the "\n" and parses its incoming command line as: "CMD=sav@#CMD=save\n", well that may not work out so well. Without knowing more about the protocol between the computer and the external device, I can't help more. Most of these communication protocols are fairly "stupid": send one line, get one line. But even that can get complex when the "receiver" doesn't get the "line" that was sent (meaning that the line termination character was missed) and you have to re-send the line.	[reply]