From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36445 invoked by alias); 31 Jan 2017 15:53:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 36424 invoked by uid 89); 31 Jan 2017 15:53:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=driven, Hx-languages-length:1524, translates, eol X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Jan 2017 15:53:34 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03D9280478; Tue, 31 Jan 2017 15:53:34 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0VFrWga015061; Tue, 31 Jan 2017 10:53:33 -0500 Subject: Re: [RFA] completion in command definition To: Jerome Guitton References: <1484058481-6378-1-git-send-email-guitton@adacore.com> <81874bfd1c99e89162b98d18fa8cb385@polymtl.ca> <20170111160518.GH27546@adacore.com> <677c2a720f77b21fd672c24efc41c878@polymtl.ca> <20170112100506.GK27546@adacore.com> <41f19570-04ab-cd04-eeb3-77170d258c43@redhat.com> <20170131142910.GA22056@adacore.com> <5e5f54dc-94f8-37a7-e081-4e729fe71938@redhat.com> <20170131152907.GM6665@adacore.com> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 31 Jan 2017 15:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170131152907.GM6665@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00667.txt.bz2 On 01/31/2017 03:29 PM, Jerome Guitton wrote: > Pedro Alves (palves@redhat.com): > >> A few minor comments below. > > Thanks again! Comments integrated. I'm just not sure about this one: > >>> + >>> + gdb_test "info break \$bpnum" \ >>> + "Num Type\[ \]+Disp Enb Address\[ \]+What.* >>> +\[0-9\]+\[\t \]+breakpoint keep y.* in main at .* >>> +\[\t \]+echo.*" >> >> I think we need to use use multi_line, to avoid problems with >> "\n" vs "\r" vs "\r\n". > > I've used the same code pattern as in break.exp; is that OK? > ISTR that on some hosts (maybe native Windows testing, but not Cygwin), we can end up with tcl/expect seeing different end lines from what we normally get on Unix, due to different levels of \n -> \r\n -> \n translation going on. Might have been on macOS, due \r being preferred there. I think tcl translates end lines to \n from files by default for input, and uses native eol for output. I think the way it's written above makes the end lines in the regexp's depend on how tcl reads eol out of the script file. So if gdb actually outputs "\r" only, the regexp won't match. Or something like that. It may be working as is due to each line ending with ".*". It's messy, and a might be a bit of cargo-culting is in place (not sure how relevant this all still is, we don't hear much about native Windows testing driven by native Windows expect, for instance), but as far as I remember, we've avoided writing multi-line regexps like that. Thanks, Pedro Alves