Log by Tracing Question 
Author Message
 Log by Tracing Question

Hi,

Exploring Expect defines a procedure where outputs of various spawned
processes can be captured in trace files:

proc logByTracing {array element op} {
  uplevel {
    global logfile

    if { [info exists logfile($expect_out(spawn_id))] } {
       set file $logfile($expect_out(spawn_id))
       log2File $file $expect_out(buffer) 0
       flush $file
    }
  }

Quote:
}

Comment: log2File is a simple proc to log data to a given file handle.

There is one problem that I have with this proc. It works great, but the
last few lines that came into the buffer before an error happens are not
logged since this procedure is only called when expect_out is used. This is
a big problem since when an error occurs it is the last few lines that are
generally more important to determine the cause of the error.

I also have an Error Handler defined which is called if an error occurs or
if control-C is pressed.

It would be nice if I could access expect_out(buffer) for each spawn_id that
is active, but I don't think that is possible. Can anyone offer a suggestion
on how I can log the last few lines that are still in the buffer? I'd like
to do this from the error handler (exit -onexit)

Thank you!



Fri, 10 Feb 2006 10:15:27 GMT  
 Log by Tracing Question

Quote:

> Exploring Expect defines a procedure where outputs of various spawned
> processes can be captured in trace files:

> proc logByTracing {array element op} {
>   uplevel {
>     global logfile

>     if { [info exists logfile($expect_out(spawn_id))] } {
>        set file $logfile($expect_out(spawn_id))
>        log2File $file $expect_out(buffer) 0
>        flush $file
>     }
>   }
> }

> Comment: log2File is a simple proc to log data to a given file handle.

> There is one problem that I have with this proc. It works great, but the
> last few lines that came into the buffer before an error happens are not
> logged since this procedure is only called when expect_out is used. This is
> a big problem since when an error occurs it is the last few lines that are
> generally more important to determine the cause of the error.

> I also have an Error Handler defined which is called if an error occurs or
> if control-C is pressed.

> It would be nice if I could access expect_out(buffer) for each spawn_id that
> is active, but I don't think that is possible. Can anyone offer a suggestion
> on how I can log the last few lines that are still in the buffer? I'd like
> to do this from the error handler (exit -onexit)

You want to do this: expect *

That will cause everything to be immediately moved from Expect's
internal buffers to expect_out(buffer) so that you can access it.

Don



Sat, 11 Feb 2006 00:19:24 GMT  
 Log by Tracing Question

Quote:
> You want to do this: expect *

> That will cause everything to be immediately moved from Expect's
> internal buffers to expect_out(buffer) so that you can access it.

> Don

Thanks! I include expect -i $spid * for all spawn ids. BTW, I really like
expect. I use it as much as I can. Also, Exploring Expect is a good book
with an excellent tutorial on tcl. That's how I learned tcl. Furthermore, it
is one of the most comprehensive books I have ever used.


Sun, 12 Feb 2006 13:00:01 GMT  
 Log by Tracing Question

Quote:


> > You want to do this: expect *

> > That will cause everything to be immediately moved from Expect's
> > internal buffers to expect_out(buffer) so that you can access it.

> > Don

> Thanks! I include expect -i $spid * for all spawn ids. BTW, I really like
> expect. I use it as much as I can. Also, Exploring Expect is a good book
> with an excellent tutorial on tcl. That's how I learned tcl. Furthermore,
it
> is one of the most comprehensive books I have ever used.

If there is any improvement I would like to see, would be to have an option
to match the shortest string as opposed to the longest match that expect
does by default.

For example given:

This is a test.
You have passed the test.

expect -re "This.*test" will match both sentences. It would be nice if a
flag (sm -- shortest match) could be provided to the expect command:

expect -sm -re "This.*test" and only match the first line. I know there are
ways to match one and only one line and then use regexp to parse the line,
but this would be simpler to use.



Sun, 12 Feb 2006 23:25:44 GMT  
 Log by Tracing Question

Quote:

> If there is any improvement I would like to see, would be to have an
option
> to match the shortest string as opposed to the longest match that expect
> does by default.

> For example given:

> This is a test.
> You have passed the test.

> expect -re "This.*test" will match both sentences. It would be nice if a
> flag (sm -- shortest match) could be provided to the expect command:

> expect -sm -re "This.*test" and only match the first line. I know there
are
> ways to match one and only one line and then use regexp to parse the line,
> but this would be simpler to use.

Tcl has had this capability (and by extension, Expect as well, if you'll
excuse the pun *grin*) since Tcl 8.1. The corresponding Expect versions are
5.31 and higher.

What you're asking for is implemented with "non-greedy" quantifiers. To make
a quantifier non-greedy, append a "?". So, you could perform the test you
desire with:

expect -re "This.*?test"

Be aware, though, that greedy and non-greedy quantifiers do *not* mix! I'd
recommend going to the Tcl'ers Wiki (http://wiki.tcl.tk) and checking out
the pages "Regular Expressions," http://wiki.tcl.tk/396, and "Drawbacks of
Tcl's Regexps," http://wiki.tcl.tk/9185, for a more detailed discussion of
the ins and outs of non-greedy expressions.

- Ken Jones, President
  Avia Training and Consulting
  www.avia-training.com
  866-TCL-HELP (866-825-4357) US Toll free
  415-643-8692 Voice
  415-643-8697 Fax



Mon, 13 Feb 2006 00:48:02 GMT  
 Log by Tracing Question

Quote:

> Tcl has had this capability (and by extension, Expect as well, if you'll
> excuse the pun *grin*) since Tcl 8.1. The corresponding Expect versions
are
> 5.31 and higher.

Great. My expect version is 5.38 and Tcl is 8.4.

Quote:

> What you're asking for is implemented with "non-greedy" quantifiers. To
make
> a quantifier non-greedy, append a "?". So, you could perform the test you
> desire with:

> expect -re "This.*?test"

This is awsome. I have been struggling with this problem for a year now.
After reading the Wiki artilces below, I am a bit confused how this would
work. The page on reg exp says that ? is a binary operator in that it would
match 0 or 1 of the atom before. So, I was thinking that:

expect -re "This.*?test"

would also match "Thistest"? Is this correct? I will try this later on
today, but I wanted to make sure how ? makes the .* non-greedy.

Quote:
> Be aware, though, that greedy and non-greedy quantifiers do *not* mix! I'd
> recommend going to the Tcl'ers Wiki (http://wiki.tcl.tk) and checking out
> the pages "Regular Expressions," http://wiki.tcl.tk/396, and "Drawbacks of
> Tcl's Regexps," http://wiki.tcl.tk/9185, for a more detailed discussion of
> the ins and outs of non-greedy expressions.

These were very good articles. Thanks.


Mon, 13 Feb 2006 23:06:49 GMT  
 Log by Tracing Question

Quote:


> > What you're asking for is implemented with "non-greedy" quantifiers. To
> make
> > a quantifier non-greedy, append a "?". So, you could perform the test
you
> > desire with:

> > expect -re "This.*?test"

> This is awsome. I have been struggling with this problem for a year now.
> After reading the Wiki artilces below, I am a bit confused how this would
> work. The page on reg exp says that ? is a binary operator in that it
would
> match 0 or 1 of the atom before. So, I was thinking that:

> expect -re "This.*?test"

> would also match "Thistest"? Is this correct? I will try this later on
> today, but I wanted to make sure how ? makes the .* non-greedy.

Your confusion is understandable, but your interpretation of the example is
correct. Unfortunately, the meaning of the "?" symbol in advanced regular
expressions is overloaded (just like the "^" character has different
interpretations depending on where it is used). It would have been better to
have selected a different character as the non-greedy modifier, but there
are so many special characters now for regular expressions, I guess it would
have been a bit difficult to have selected another one.

Anyway, the "?" character still has its old interpretation as a "0 or 1
occurrence of the previous atom" quantifier if it immediately follows the
atom. Thus, "/?" matches 0 or 1 occurrences of a "/", and "(na)?" matches 0
or 1 occurrences of the substring "na".

The "?" has an additional interpretation as a non-greedy modifier when it
*immediately follows* another quantifier. In other words, "a+?" matches 1 or
more occurrences of "a", but prefers as few occurrences as possible while
still matching the rest of the regular expression (if any). And thus the
example above, "This.*?test", means to match "This" followed by 0 or more oc
currences of any characters -- preferring as few characters as possible --
followed by "test".

The "?" non-greedy quantifier can be applied to any quantifier, though I've
not had call to use it with any except "*" and "+". For example, "\d{4,8}?"
means to match anything from 4 to 8 digits, but prefer fewer, so given
"12345678" it would match only "1234". And "(\.com)??" means match 0 or 1
occurrences of ".com", but prefer 0.

Actually, I'll put out a call for help on these last examples. I've yet come
across any situation where I've needed to use the "??", "{m,n}?" or "{m,}?"
quantifiers. Has *anybody* done so in a real-life situation? I'd love to
include them as examples in my course modules on regular expressions,
because the ones I've got now are bogus. :-)

- Ken Jones, President
  Avia Training and Consulting
  www.avia-training.com
  866-TCL-HELP (866-825-4357) US Toll free
  415-643-8692 Voice
  415-643-8697 Fax



Tue, 14 Feb 2006 01:42:02 GMT  
 Log by Tracing Question

Thank you for your help. I tried the ? operator to make .* non greedy (.*?)
and it worked beutifully. It greately simplified my regular expression.

Your explanation was very thorough I appreciate your help. Tcl is a
wonderful language. I have really come to like it a lot. Compared to perl it
is so much cleaner and just better. Java? I am still not too sure about
java. I think java got some of its ideas from tcl. This is just my feeling,
not sure how accurate it is. I hate the error messages in java, and it is
overly complicated with its classes that come with it. People have done a
good job designing tcl. The basic design (which I don't profess to be an
expert on) seems very well thought of.



Wed, 15 Feb 2006 19:17:59 GMT  
 Log by Tracing Question

Ken Jones wrote an excellent explanation:

Quote:
> The "?" non-greedy quantifier can be applied to any quantifier, though I've
> not had call to use it with any except "*" and "+". For example, "\d{4,8}?"
> means to match anything from 4 to 8 digits, but prefer fewer, so given
> "12345678" it would match only "1234". And "(\.com)??" means match 0 or 1
> occurrences of ".com", but prefer 0.

> Actually, I'll put out a call for help on these last examples. I've yet come
> across any situation where I've needed to use the "??", "{m,n}?" or "{m,}?"
> quantifiers. Has *anybody* done so in a real-life situation? I'd love to
> include them as examples in my course modules on regular expressions,
> because the ones I've got now are bogus. :-)

I've never needed one of those cases, and I bet it is pretty rare.

Generally one uses * or + to grab an unknown bunch of stuff between
known entities - in which case there are man reasons you might want
to make a minimum v maximum match length yo keep from grabbing up
too much stuff (including the thing you were trying to match after
the * or +

In the case of more specifically quantified this is much less likely
to happen, If I use <atom>? it is usually because <atom> is a single
optional requirement - but if it is there I would want it to match.
and if I've used <atom>{m,n} 've already bounded the number of things
it'll match & once again the likelyhood of that match going overboard
is slim.

And on a further note, in looking thru code, questions, etc I find that
* and + are far more common in general usage than {m,n}

Bruce



Wed, 15 Feb 2006 23:06:40 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Another log by tracing question

2. Expect: Log by tracing question

3. trace log in error

4. Problem with logging multiple processes in Expect via trace

5. Expect: Help with Logging by Tracing

6. Stumper Question for me: simple question for this group -exponential and logs

7. command traces interfere with step traces (bug?)

8. TIP #102: Change [trace list] to [trace info]

9. trace on & trace off

10. Sorting with O(n.log(log(n)))

11. Scratchy 0.5 - Report Generator and Log Parser for Apache access logs

12. VA - tracing question

 

 
Powered by phpBB® Forum Software