This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: GDB needs a --cmdline option
- To: Mo DeJong <mdejong at cygnus dot com>
- Subject: Re: GDB needs a --cmdline option
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 08 May 2000 09:50:30 +1000
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <Pine.SOL.3.91.1000507154133.21631E-100000@cse.cygnus.com>
Mo DeJong wrote:
> gdb gcj --cmdline "-C *.java gnu/gcj/convert/*.java gnu/gcj/*.java"
>
> So I went off and hacked something together to do
> that. The patch for gdb from the sourceware CVS is
> appended to this email.
>
> So question 1 is, do other folks think this --cmdline
> option is a good idea?
I think you've identifed two separate problems:
o there should be a way of passing individual
commands to GDB on the command line
(rather than having to shove them in a file)
o there should be a convenient reliable mechanism
for passing commands through on the command
line
As your patch currently stands, it sits half way between the two.
Rather than your --cmdline what about a more generic:
gdb ggg .. --this-is-a-command "set args *.java
gnu/gcj/convert/*.java..." ...
as a more convenient way of passing in general commands on the command
line (which can include set args). For the argument list, perhaphs:
$ gcj -C *.java gnu/gcj/convert/*.java gnu/gcj/*.java
$ gdb -- !$
However, I should note that this last one isn't trivial as the code
would need to escape the accumulated arguments so that they are not
re-evaluated by the sub-shell. For that reason, just the first, and far
more generic option might be the better thing to persue.
An important issue your patch does address (yow!), is the need to retain
evaluation ordering. The implied ordering of:
gdb ggg -x file-set-args --cmdline ... -x file-set-args
must be retained.
> If you answered yes on question 1, then what could be
> done to improve the patch so that it is up to
> gdb standards? I heard from a couple of folks that
> it might not be a good idea to clobber an existing
> .gdbcmdline file (if it existed) and that it might
> be better to remove the file after it was sourced.
I'd suggest the following:
o Instead of creating/clibering the .gdbcmdline
file, I think you could implement this using
just local buffering. An internal list of
commands say? I can't see any reason to
create a file. (the current directory may
be readonly, the file may exist, ....)
o Rather than falling through to the ``-x'' code
(bad for long-term maintainability) I'd suggest
thinking about an improved mechanism that allows
you to accumulate both commands and scripts.
enjoy,
Andrew
PS: It's ``xyz ()'' not ``xyz()'' and yes it does take some getting
accustomed to :-)
PPS: Once integrated I think the idea will be wildly popular.