Remove HISTSIZE env var altogether? (was: Re: [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999])
Patrick Palka
patrick@parcs.ath.cx
Fri May 22 12:10:00 GMT 2015
On Fri, May 22, 2015 at 7:57 AM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> 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.
... but since the work to rename it to GDBHISTSIZE has already been
done, we might as well keep it :)
>
>>
>> Thanks,
>> Pedro Alves
>>
More information about the Gdb-patches
mailing list