From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25570 invoked by alias); 4 Aug 2005 20:37:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25255 invoked by uid 22791); 4 Aug 2005 20:37:07 -0000 Received: from lakermmtao08.cox.net (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 04 Aug 2005 20:37:07 +0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050804203705.HXFM23463.lakermmtao08.cox.net@white> for ; Thu, 4 Aug 2005 16:37:05 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1E0mSe-0001F3-00 for ; Thu, 04 Aug 2005 16:37:04 -0400 Date: Thu, 04 Aug 2005 20:37:00 -0000 From: Bob Rossi To: gdb-patches@sources.redhat.com Subject: Re: Fully anchor mi_gdb_test expected results. Message-ID: <20050804203704.GA4472@white> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050804025045.GC32108@white> <20050804041121.GB29482@nevyn.them.org> <20050804140937.GB4054@white> <20050804141750.GA11536@nevyn.them.org> <20050804142601.GC4054@white> <20050804143238.GA11996@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050804143238.GA11996@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-08/txt/msg00070.txt.bz2 On Thu, Aug 04, 2005 at 10:32:38AM -0400, Daniel Jacobowitz wrote: > 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 > } This doesn't seem to work for the " character. Here's the input to string_to_regexp, 555-break-insert -t "\"basics.c\":28" Here's the output, 555-break-insert -t "\"basics\.c\":28" Here is what I need to pass the test (which I hand wrote), -break-insert -t \"\\\\\"basics.c\\\\\":28\" It's a little odd. The quote needs to be escaped once, which makes perfect sense to me. The \ char needs to be escaped with 3 back slashes, to make a total of 4. This is a little odd to me. Is that what string_to_regexp does? Any ideas? Thanks, Bob Rossi