From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94422 invoked by alias); 22 May 2015 11:58: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 94410 invoked by uid 89); 22 May 2015 11:58: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-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 May 2015 11:58:17 +0000 Received: by oige141 with SMTP id e141so11979647oig.1 for ; Fri, 22 May 2015 04:58:15 -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=LWNMu/4z+HswW8ielkC0LU8loJWwTbQC8jf7u9zs4I0=; b=PcTSKoHi4RtZ50m4HFYs41eIVtpizN7RU1kZSZbt82yQEHRxHQiRYhnAufvINM5l8F lTA/PoYeam+miP2lmzCEezxyHuRSbMRBZAGEE/0W9TBm5Y/sW22jJGlA09UwxYzdvW/7 y/QhiNyWj7IepEiRxvvVrYsT85hhSgGzjXfO3N5prjjMP/I497KHm8EoLvBHq5lh+4Tj fIu3rRQvsCaDQTF6c93MyzjzLOext4zq3/vKrc+3OJ/e552qlJfdp8OyDjVm78T91ow/ YGuYI3j3+1oklDDwpQdu+yMs1WEfPGSB2Lb32obRH60Y4h2qF752lGemNgd8sBFza+h1 w52A== X-Gm-Message-State: ALoCoQnhVcUXcuE3p+FqhSq0w8yXjOezjqY8DIF5YOH0DWJLyQq5hSr3esPOKm7L/y51se9ip86b X-Received: by 10.182.211.66 with SMTP id na2mr6334945obc.43.1432295895502; Fri, 22 May 2015 04:58:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.243.232 with HTTP; Fri, 22 May 2015 04:57:54 -0700 (PDT) In-Reply-To: <555EFE3F.2080903@redhat.com> 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 11:58: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/msg00606.txt.bz2 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. > > Thanks, > Pedro Alves >