From: Pedro Alves <pedro@palves.net>
To: Lancelot SIX <lsix@lancelotsix.com>,
Guinevere Larsen <blarsen@redhat.com>
Cc: gdb@sourceware.org
Subject: Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023)
Date: Fri, 29 Sep 2023 10:52:34 +0100 [thread overview]
Message-ID: <636abef0-7d22-e294-7f31-21f98ad3eb2a@palves.net> (raw)
In-Reply-To: <20230929092410.u4j5i73bpg5ictyw@octopus>
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?
>
> 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.
next prev parent reply other threads:[~2023-09-29 9:52 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
2023-09-27 14:00 ` Guinevere Larsen
2023-09-29 9:24 ` Lancelot SIX
2023-09-29 9:52 ` Pedro Alves [this message]
2023-09-29 10:30 ` Turn history saving on by default? (Re: GDB BoF notes - GNU Cauldron 2023) Guinevere Larsen
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
2023-09-29 10:25 ` Pedro Alves
2023-10-05 7:08 ` Tom de Vries
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=636abef0-7d22-e294-7f31-21f98ad3eb2a@palves.net \
--to=pedro@palves.net \
--cc=blarsen@redhat.com \
--cc=gdb@sourceware.org \
--cc=lsix@lancelotsix.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).