From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30421 invoked by alias); 4 Aug 2005 20:48:05 -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 30413 invoked by uid 22791); 4 Aug 2005 20:48:02 -0000 Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 04 Aug 2005 20:48:02 +0000 Received: from white ([68.9.64.121]) by eastrmmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050804204757.XKCK12912.eastrmmtao01.cox.net@white> for ; Thu, 4 Aug 2005 16:47:57 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1E0mdA-0001FP-00 for ; Thu, 04 Aug 2005 16:47:56 -0400 Date: Thu, 04 Aug 2005 20:48:00 -0000 From: Bob Rossi To: gdb-patches@sources.redhat.com Subject: Re: Fully anchor mi_gdb_test expected results. Message-ID: <20050804204756.GB4472@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> <20050804203704.GA4472@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050804203704.GA4472@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-08/txt/msg00071.txt.bz2 On Thu, Aug 04, 2005 at 04:37:04PM -0400, Bob Rossi wrote: > 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? For instance, a change from regsub -all {[]*+.|()^$\[]} $str {\\&} result to regsub -all {[]*+."|()^$\[]} $str {\\&} result escapes the quotes. Would a change like this be OK? I'll run the testsuite. Thanks, Bob Rossi