From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78555 invoked by alias); 2 Jun 2015 15:47:21 -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 78525 invoked by uid 89); 2 Jun 2015 15:47:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-oi0-f46.google.com Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com) (209.85.218.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 02 Jun 2015 15:47:20 +0000 Received: by oiww2 with SMTP id w2so128818517oiw.0 for ; Tue, 02 Jun 2015 08:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/Rp68UHDb/5xTgu330z00btr60JRtV0//TJsiMIOyvU=; b=SmawJ7c76HeWyjKr/cKG5aIeVm+fuYHX2pJSlVXeV0cM2r/MGee5gndrra4Ww0LYNG TGATdEZd9ijA0ajt2hjcO28/vFQ6/bwUMnbM8iiwa6sSirtDuIxQ8TqhNCEu25Opw1C1 4QAOaFK2lyoN6JV4Y5B/zzEYV+rFc6XPh/IImTDANE1E0McxTZTgM+qElmDySqZIO0WY RznkbLIAGg9z6bVoo2gu9NjqrvEyu8Ffe1Dp3IAoM8Nr4++eZptRcP2t8q7ohlzQ7+k9 L1pXeOkcVk7p/CuXeNEfecSrpUmR/d+yHIQlkaa+BBtEl3/LxLGSd5bqnYfv28USt49I LhZQ== X-Gm-Message-State: ALoCoQmwLaDXQNAVh8C9i5Uwi3W+QuQdiO8GwUQsq5mep7xEH9vOsQUgbnxUkG9akL1tExr2crBF X-Received: by 10.182.81.229 with SMTP id d5mr4948610oby.28.1433260038021; Tue, 02 Jun 2015 08:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Tue, 2 Jun 2015 08:46:57 -0700 (PDT) In-Reply-To: <83fv6arvrm.fsf@gnu.org> References: <1433252358-26692-1-git-send-email-patrick@parcs.ath.cx> <83fv6arvrm.fsf@gnu.org> From: Patrick Palka Date: Tue, 02 Jun 2015 15:47:00 -0000 Message-ID: Subject: Re: [PATCH] [RFC] Discard local stdin events while an attached inferior is running To: Eli Zaretskii Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00028.txt.bz2 On Tue, Jun 2, 2015 at 11:10 AM, Eli Zaretskii wrote: >> From: Patrick Palka >> Cc: Patrick Palka >> Date: Tue, 2 Jun 2015 09:39:18 -0400 >> >> This patch attempts to work around an annoying typo that I (and others, >> I assume) commonly make while debugging an attached (not forked) >> process. That is, I sometimes type "continue\n\n" instead of >> "continue\n" when I want to resume the inferior. By doing so, the >> inferior gets resumed and the extraneous "\n" gets buffered. But once >> GDB regains control, the extraneous "\n" gets read and so an empty >> command line is submitted to readline. This is shorthand for running >> the previous command again. So effectively typing "continue\n\n" will >> run "continue" twice. Running "continue" twice instead of once can have >> irreversible consequences to the debugging session and thus is pretty >> annoying to deal with. >> >> To work around this kind of typo, this patch installs a dummy event >> handler that discards all local stdin events that occur when the >> attached inferior is (synchronously) running. >> >> The obvious side-effect of this patch is that dexterous users can no >> longer "queue" commands while an attached inferior is running, e.g. >> type "continue\nprint foo" with the intention of "print foo" being run >> as soon as GDB regains control. I personally don't make use of this >> ability very much. > > IMO, this incompatible change of behavior should at least have an > option to get the old behavior back, and that option should possibly > be off by default. > > In any case, there should be a NEWS entry and a patch for the manual > which describe this unusual feature. Will do, if there is enough support for this change to go forward. > >> Is this typo a common occurrence for anyone else? > > Not common, but sometimes. However, I sometimes type ahead future > commands without waiting for the prompt, for example, when I know I'll > need a lot of CR presses. Yeah, unfortunately it is impossible to determine whether a key press was a typo or not :( An alternative solution is to provide an option to disable the repeat-command shorthand altogether. It is slightly unintuitive, typo-prone, and hardly an improvement over the well-known ^P key combination.