Re: Fully anchor mi_gdb_test expected results.

[Bob Rossi <bob at brasko dot net>]

> >   which simply allows any data at the beggining of the match. So I could
> >   easily modify an MI command to output "HAHAHA, YOU CAN'T TEST ME", as
> >   the first thing it outputs, and it would go unnoticed in the
> >   testsuite. Probably the reason this could not have been done before is
> >   because the MI input command was being echo'd back, and it would be
> >   complicated to match that data.
> 
> I am suggesting anchoring the pattern with a copy of what you expect to
> be echoed.  We already have code to escape a string into a regex.  We
> know what we sent to GDB.

I originally tried this, but failed because I did *not* know how to
escape a string into a regex. Is there a function written that does
this? I'll try it. 

> If you think that's too much trouble, could you alternatively try "stty
> -echo" in expect, rather than send_gdb "shell stty -echo"?

This was the original path I went down. However, I couldn't figure out
what the heck remote_spawn is. There is no documentation anywere (that I
could find). So, does remote_spawn call spawn? Does it take the same
arguments as spawn?

> >      - Make sure every test has the GDB expected pattern be the absolute
> >        beginning of the MI output command. Then I could assume in the
> >        general purpose match that the pattern was the beggining. It
> >        would look something like this,
> >          -re "^.*($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)$" {
> >        I don't like this approach because it makes the testcase do
> >        specific things in order to make sure that the syntax checking
> >        was done properly.
> 
> I've got no idea what you mean by this, but anchoring .* at the front
> of a pattern doesn't accomplish anything!

It doesn't matter anyways, if you like the idea of the 2 above
approaches.

Thanks,
Bob Rossi