From: Doug Evans <dje@transmeta.com>
To: Joel Brobecker <brobecker@gnat.com>
Cc: Matt Thomas <matt@3am-software.com>, gdb@sources.redhat.com
Subject: Re: breakpoint commands and finish
Date: Mon, 14 Apr 2003 22:27:00 -0000 [thread overview]
Message-ID: <16027.13708.106260.478427@casey.transmeta.com> (raw)
In-Reply-To: <20030414213340.GJ1151@gnat.com>
Joel Brobecker writes:
> However, in this particular case, I think that it was very easy to find
> the information. The person was asking what the behavior of a "commands"
> should be: the answer to his question is right there in the section
> documenting the commands lists.
>
> > It'd be nice if people got in the habit of specifying where exactly
> > in the documentation to look. e.g.
>
> I disagree, unless the information is buried somewhere not obvious.
> One very important lesson I learnt at university is how to find the
> information myself. In this particular cases, all you have to do is
> check the index, click on the name of the command you are interested
> in "commands" in that case, and voila! The answer is right there.
> I believe that actually letting people search themselves the location
> of the information they are looking for is helpful.
Nice in theory (and academia ...). In practice it often just annoys people.
("You had the answer right in front of you." (*1))
Sure, learning the info program (s/info/favorite/) is a useful thing
to encourage. It's the forcing of when to spend the time that I question,
it may be an inopportune time for the asker (otherwise s/he might have
spent more time rtfm-ing ...).
And the obvious place to look isn't necessarily obvious to the person
asking the question (leading to more time spent).
Whether such things apply in this particular case I dunno.
Clearly Matt's first guess of where to look didn't work.
At what point one should give up and ask for help (and the inevitable
retribution for giving up too early) is always a minefield.
> (BTW: I did give the answer to the question when it was asked a few days ago)
Well, one can quibble over this but no matter.
One can certainly argue this meta-discussion has gone on too long already.
---
bash$ info -f gdb.info -n 'Break Commands'
and grep for ignored.
-->
Any other commands in the command list, after a command that resumes
execution, are ignored. This is because any time you resume execution
(even with a simple `next' or `step'), you may encounter another
breakpoint--which could have its own command list, leading to
ambiguities about which list to execute.
---
(*1): No suggestion is made that that was necessarily the case here.
And no claim is made that one should always find the place in the manual
first. But if you know it or know how to trivially find it, holding it
back is what I'm questioning.
next prev parent reply other threads:[~2003-04-14 22:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 20:56 Matt Thomas
2003-04-14 21:00 ` Joel Brobecker
2003-04-14 21:04 ` Joel Brobecker
2003-04-14 21:11 ` Doug Evans
2003-04-14 21:33 ` Joel Brobecker
2003-04-14 22:27 ` Doug Evans [this message]
2003-04-14 21:23 ` Matt Thomas
2003-04-17 17:47 ` Michael Snyder
2003-04-17 18:48 ` Matt Thomas
2003-04-17 20:19 ` Daniel Jacobowitz
2003-04-17 20:44 ` Doug Evans
2003-04-17 20:50 ` Daniel Jacobowitz
2003-04-17 21:19 ` Doug Evans
2003-04-17 21:44 ` Daniel Jacobowitz
2003-04-17 23:11 ` return value of a gdb command Smita
2003-04-17 23:13 ` Daniel Jacobowitz
2003-04-18 12:10 ` Bob Rossi
2003-04-18 13:38 ` Daniel Jacobowitz
2003-04-21 20:55 ` Andrew Cagney
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=16027.13708.106260.478427@casey.transmeta.com \
--to=dje@transmeta.com \
--cc=brobecker@gnat.com \
--cc=gdb@sources.redhat.com \
--cc=matt@3am-software.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