Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Patrick Palka <patrick@parcs.ath.cx>
To: Pedro Alves <palves@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: Remove HISTSIZE env var altogether? (was: Re: [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999])
Date: Fri, 22 May 2015 11:58:00 -0000	[thread overview]
Message-ID: <CA+C-WL-+keJAiCJBa4bCKmhBH7Wtp9Gi5k7aFwLGtb7q+9DWyQ@mail.gmail.com> (raw)
In-Reply-To: <555EFE3F.2080903@redhat.com>

On Fri, May 22, 2015 at 6:00 AM, Pedro Alves <palves@redhat.com> 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
>


  reply	other threads:[~2015-05-22 11:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-21 22:51 [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999] Patrick Palka
2015-05-21 23:33 ` Pedro Alves
2015-05-22  0:26   ` Patrick Palka
2015-05-22  0:42     ` Pedro Alves
2015-05-22  0:56       ` Patrick Palka
2015-05-22  2:47         ` Patrick Palka
2015-05-22 10:00           ` Remove HISTSIZE env var altogether? (was: Re: [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999]) Pedro Alves
2015-05-22 11:58             ` Patrick Palka [this message]
2015-05-22 12:10               ` Patrick Palka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+C-WL-+keJAiCJBa4bCKmhBH7Wtp9Gi5k7aFwLGtb7q+9DWyQ@mail.gmail.com \
    --to=patrick@parcs.ath.cx \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox