Re: Fully anchor mi_gdb_test expected results.

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Aug 04, 2005 at 10:26:01AM -0400, Bob Rossi wrote:
> > >   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. 

# Given an input string, adds backslashes as needed to create a
# regexp that will match the string.

proc string_to_regexp {str} {
    set result $str
    regsub -all {[]*+.|()^$\[]} $str {\\&} result
    return $result
}


> > 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?

It's part of DejaGNU.

# If the command is successfully started, a positive "spawn id" is returned.
# If the spawn fails, a negative value will be returned.

That spawn ID should suffice.  I'd rather match the echoed text though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC