From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108904 invoked by alias); 22 May 2015 12:10:06 -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 108889 invoked by uid 89); 22 May 2015 12:10:05 -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-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 May 2015 12:10:04 +0000 Received: by oihd6 with SMTP id d6so12166961oih.2 for ; Fri, 22 May 2015 05:10:02 -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=KQfBxXmavqQoiDmlpg4JYiY5MFmzYV53aAVOLt0IbZU=; b=ZZFQm40xKPkT63sqhQDxQOK6YG8VFdkDcRujVuCsc3prVllq604kQLROOH3bjrIKvV I6xrtiSN9i7edlEcGhdFIK1Po/mYH4ehc/HHUNlnn+amd+nDeb/tIuQsJiVviazNPJka amWuDFzZehmrNdGN9ezOW22Yh6bpysGa8F0QIoNlYs8v225d0v+Fws/2ZdyeUXEs3a7z Zv+S72Wh5YzApwEnVTm6lRVWube06I8pd85Id0OoLtikQELTKZsC6/4bwFaD5mv4OjP3 3D/tjXlanikJwuXPNhlr01URVGvdAExXCE/u5O+MlheaqU+SZIDoS5PlrlOb2CzSQfYX OkYA== X-Gm-Message-State: ALoCoQnIIDk2SCajewtqZVlJOXOMjVDxrFd0ggyNqivvNDn6mYue+dLuadB6OzlDHW9dPvEGWwey X-Received: by 10.60.101.195 with SMTP id fi3mr4337469oeb.65.1432296602872; Fri, 22 May 2015 05:10:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.243.232 with HTTP; Fri, 22 May 2015 05:09:42 -0700 (PDT) In-Reply-To: References: <1432248648-7402-1-git-send-email-patrick@parcs.ath.cx> <555E6B60.8040802@redhat.com> <555E7B52.6050100@redhat.com> <555EFE3F.2080903@redhat.com> From: Patrick Palka Date: Fri, 22 May 2015 12:10:00 -0000 Message-ID: Subject: Re: Remove HISTSIZE env var altogether? (was: Re: [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999]) To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-05/txt/msg00607.txt.bz2 On Fri, May 22, 2015 at 7:57 AM, Patrick Palka wrote: > On Fri, May 22, 2015 at 6:00 AM, Pedro Alves wrote: >> Changing title to call for attention. Maybe we should ask >> on gdb@. Background here: >> >> https://sourceware.org/ml/gdb-patches/2015-05/msg00349.html >> https://sourceware.org/ml/gdb-patches/2015-05/msg00563.html >> >>> What do you think about removing HISTSIZE/GDBHISTSIZE support >>> altogether? It is awfully redundant (we can already automatically set >>> the history size via .gdbinit or via -ex "set history size foo") and >>> thus not really useful. Even if we go along with replacing HISTSIZE >>> with GDBHISTSIZE I just can't see much use for it. >> >> What about GDBHISTFILE? I think that the rationale for the existence >> of one should apply to both. (with the HISTSIZE vs GDBHISTSIZE distinction >> being a separate matter.) > > GDBHISTFILE is less useless than HISTSIZE I think. I can imagine > unique use cases for GDBHISTFILE (e.g. to have separate per-project > history files) whereas for HISTSIZE, not so much. So I don't think > their usefulness can be conflated. > >> >> I'm really not sure. Trying to play devil's advocate: >> >> #1 - An env var can be set once, for all users. But that can be >> done with --with-system-gdbinit=FILE as well. >> >> #2 - Along with GDBHISTFILE, it survives -nx. Does it really matter? >> I don't know. >> >> #3 - Seems friendly to allow at least GDBHISTFILE be an env var so it >> can easily be toggled per host. Though that can be done through >> Python inside .gdbinit nowadays. Though^2, Python isn't always >> available. >> >> OTOH, I'm getting more convinced that we should at least >> rename HISTSIZE -> GDBHISTSIZE. The cost of keeping that >> doesn't seem to be much. > > I just don't see any utility in this environment variable. I imagine > most users stumble upon this feature by realizing that their global > HISTSIZE variable is being read by GDB. Once we rename it to > GDBHISTSIZE we will no longer have this coincidence and the variable > will be forever ignored. ... but since the work to rename it to GDBHISTSIZE has already been done, we might as well keep it :) > >> >> Thanks, >> Pedro Alves >>