Re: Remove HISTSIZE env var altogether? (was: Re: [PATCH] Tweak the handling of $HISTSIZE edge cases [PR gdb/16999])

[Patrick Palka <patrick@parcs.ath.cx>]

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
>>