From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: mbilal <mbilal@codesourcery.com>,
gdb-patches@sourceware.org, tromey@redhat.com
Subject: Re: Fwd: [PATCH] Fix for PR gdb/15224 should "set history save on" by default
Date: Wed, 03 Apr 2013 17:14:00 -0000 [thread overview]
Message-ID: <515C3247.3050408@redhat.com> (raw)
In-Reply-To: <20130402152617.GA16641@host2.jankratochvil.net>
On 04/02/2013 04:26 PM, Jan Kratochvil wrote:
> On Mon, 01 Apr 2013 16:15:11 +0200, Pedro Alves wrote:
>> On 04/01/2013 01:29 PM, Jan Kratochvil wrote:
>>>>> The history's filename is also tweakable with the GDBHISTFILE
>>>>> environment variable (there's HISTSIZE too; 'GDBHISTFILE= gdb' effectively
>>>>> disables history load/save). Doesn't feel quite right to tie this to .gdbinit.
>>> It matters how are the existing environments set up. And by default neither
>>> HISTSIZE nor GDBHISTFILE environment variables are set.
>>
>> Not clear to me which environments you're referring to here,
>
> How >90% of GDB users run it.
>
>
>> if you're referring to any specific environments. (HISTSIZE won't be as rare,
>> because that's also the variable used by bash. We should probably
>> have a GDBHISTSIZE too.)
>
> I meant >90% of GDB users do not have GDBHISTFILE environment variables set.
Ack. It just sounded from the wording you were thinking of some specific
case.
> I tested now that "ddd" will store the history commands like "step".
> But as it runs GBD with "gdb -q -fullname PROGNAME" it already happens if one
> has "set history save on" in ~/.gdbinit so I would not call that a regression.
Yeah. The history size is 256 by default, so IMO it's no big issue. It'd be
worse if the history file could grow unbounded by default, IMO.
I didn't realize ddd used annotations... I've updated the wiki's frontend
hall of shame^Wfame: http://sourceware.org/gdb/wiki/GDB%20Front%20Ends
>
> http://pkgs.fedoraproject.org/cgit/gdb.git/plain/gdb-6.5-BEA-testsuite.patch
> is using:
> cat gdbscript.gdb /dev/zero | gdb -nx "./$(basename "$RUNME")" > $LOG
> which should get handled by existing ISATTY in GDB.
Good.
> This command works for me:
> unset GDBHISTFILE; gdb -ex "set history filename .gdb_history"
Indeed it works. I actually didn't think to try it. I read:
tmpenv = getenv ("GDBHISTFILE");
if (tmpenv)
history_filename = xstrdup (tmpenv);
else if (!history_filename)
{
/* We include the current directory so that if the user changes
directories the file written will be the same as the one
that was read. */
#ifdef __MSDOS__
/* No leading dots in file names are allowed on MSDOS. */
history_filename = concat (current_directory, "/_gdb_history",
(char *)NULL);
#else
history_filename = concat (current_directory, "/.gdb_history",
(char *)NULL);
#endif
}
read_history (history_filename);
noticed the explicit current directory handling and assumed it didn't.
But, it doesn't work the same. Vis.:
$ gdb
(gdb) show history filename
The filename in which to record the command history is "/tmp/.gdb_history".
(gdb) q
Notice, absolute path above.
$ cd /tmp
$ mkdir a
$ gdb -ex "set history filename .gdbhist"
(gdb) show history filename
The filename in which to record the command history is ".gdbhist".
(gdb) cd a
Working directory /tmp/a.
(gdb) q
$ cat a/.gdbhist
show history filename
cd a
q
$ ls .gdbhist a/.gdbhist
ls: cannot access .gdbhist: No such file or directory
a/.gdbhist
$
So, the current default resolves the relative .gdb_history path
early on, meaning, the history file written is the same that was
read, while "set history filename .gdb_history" resolves to
different files at read and at write times, as seen in the example
above. I'd call that a bug too.
>
> I do not understand why you mention $cwd, what $cwd should do differently?
Not necessary it seems then. The above issue should be addressed though.
Probably by making "set history filename"'s set hook resolve the path.
Whether to make "show history filename" show just the resolved path, or
both, I'm undecided.
>
> I was expecting that by default
> cd /tmp; (unset GDBHISTFILE; gdb -nx)
> will change from
> (gdb) show history filename
> The filename in which to record the command history is "/tmp/.gdb_history".
> to
> (gdb) show history filename
> The filename in which to record the command history is "/home/user/.gdb_history".
Right.
--
Pedro Alves
next prev parent reply other threads:[~2013-04-03 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51558CB4.8010003@codesourcery.com>
2013-03-29 16:18 ` mbilal
2013-03-29 16:28 ` Jan Kratochvil
2013-04-01 11:34 ` Pedro Alves
2013-04-01 12:41 ` Jan Kratochvil
2013-04-01 19:44 ` Pedro Alves
2013-04-02 17:10 ` Jan Kratochvil
2013-04-03 17:14 ` Pedro Alves [this message]
2013-04-03 17:50 ` Jan Kratochvil
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=515C3247.3050408@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=mbilal@codesourcery.com \
--cc=tromey@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