Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Guinevere Larsen via Gdb <gdb@sourceware.org>
To: Pedro Alves <pedro@palves.net>, Lancelot SIX <lsix@lancelotsix.com>
Cc: gdb@sourceware.org
Subject: Re: Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)
Date: Fri, 29 Sep 2023 12:30:20 +0200	[thread overview]
Message-ID: <9440ee6a-ae85-453b-8129-e8674281d4f4@redhat.com> (raw)
In-Reply-To: <636abef0-7d22-e294-7f31-21f98ad3eb2a@palves.net>

On 29/09/2023 11:52, Pedro Alves wrote:
> On 2023-09-29 10:24, Lancelot SIX wrote:
>>>> - Revisiting defaults
>>>>
>>>>     - Can we turn history saving on by default?  Maybe default to
>>>>       history on home dir by default, too (~/.gdb_history).  That would
>>>>       align us with bash.  Some in the room have had this enabled in
>>>>       their gdbinits for so long they no longer remembered this wasn't
>>>>       on by default.  Others weren't even aware you can turn this on.
>>> One issue I find with the bash approach is that you end up mixing history
>>> between multiple unrelated sessions. Bash can't solve this but GDB possibly
>>> could.
>>>
>>> My suggestion would be to use an approach similar to vim's swap files. As an
>>> example, editing the maintainers file, I have the file ~/.local/state/nvim/swap/%home%blarsen%Documents%binutils-gdb%gdb%MAINTAINERS.swp;
>>> This way you can have histories specific to any binary you're debugging
>>> without mixing sessions.
>>>
>> Hi,
>>
>> With such approach, I am not really sure how to name/identify a session.
>> Is that based on the name of the binary you're debugging?  If so what
>> happens if you use `file another_bin`?  Either you switch to another
>> "session", but really you never left GDB so that would seem odd to me,
>> or you end up having history about another_bin in your first apparently
>> unrelated session.
> Of what happens if you start GDB without a binary at all?
Yeah, those are good points. Any way to fix this is way over-engineering 
compared to just "local histories in each folder".
>
>> Similarly, when dealing with multiple inferiors, would running `inferior
>> N` switch from session to session?
>>
>> I can see cases where such behavior could be helpful, but there seems
>> to be a lot of edge cases where it could become strange.
>>
>> My feeling for now is that the best way to achieve this is to save the
>> gdb history in the current directory, with the "risk" of having plenty
>> of history files left all-over the place (as you mentioned already).
>>
>> I feel that having the default somewhere under $HOME / $XDG_STATE_HOME
>> (as suggested by Tom) seems an "easier" default.
>>
> My thoughts exactly.  +1.
>
> On my bash for example, I got recently annoyed with
> all my ssh shells overwriting the same history file, so I came up with a way to
> have easy separate bash history sessions.  But, I still think that the bash default
> is OK.
>
> The only viable options that I can think of for gdb are:
>
> #1 - don't save history  (current default)
> #2 - save history in current dir
> #3 - save history in $HOME (or somewhere XDG if it makes system for the system)
>
> #1 is of course the current default.
>
> #2 is what I do in my .gdbinit:
>
>   set history save on
>   set history filename .gdb_history
>   set history size unlimited
>
> This works well enough for me.  It does have the downside of sprinkling .gdb_history files all
> over the place, which gets a bit annoying at times.  E.g., sometimes I'll spawn gdb in a random
> directory because I often use gdb as my calculator :-)  ("(gdb) p 1 + 2 * 3", etc.),
> which ends up with a .gdb_history file in that dir.  Still, it's my choice, and
> I am aware of the consequences.
>
> #3 seems like a reasonable default to me, which doesn't have that "sprinkle files
> throughout the filesystem" issue.
>
Yeah, I think I agree. This can still be over-written by a user that 
wants separate histories, and having mixed ones is better than nothing 
at all. +1 for making 3 the default

-- 
Cheers,
Guinevere Larsen
She/Her/Hers


  reply	other threads:[~2023-09-29 10:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 12:41 GDB BoF notes - GNU Cauldron 2023 Pedro Alves
2023-09-27 13:55 ` Simon Marchi via Gdb
2023-09-27 14:00 ` Guinevere Larsen via Gdb
2023-09-29  9:24   ` Lancelot SIX via Gdb
2023-09-29  9:52     ` Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023) Pedro Alves
2023-09-29 10:30       ` Guinevere Larsen via Gdb [this message]
2023-09-27 20:27 ` GDB BoF notes - GNU Cauldron 2023 John Baldwin
2023-09-29  9:57   ` Pedro Alves
2023-10-06 21:35     ` John Baldwin
2023-09-28 20:44 ` Tom Tromey
2023-09-29  4:48   ` Sam James via Gdb
2023-09-29 10:25   ` Pedro Alves
2023-10-05  7:08 ` Tom de Vries via Gdb

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=9440ee6a-ae85-453b-8129-e8674281d4f4@redhat.com \
    --to=gdb@sourceware.org \
    --cc=blarsen@redhat.com \
    --cc=lsix@lancelotsix.com \
    --cc=pedro@palves.net \
    /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