From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 788 invoked by alias); 14 Apr 2003 22:27:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 780 invoked from network); 14 Apr 2003 22:27:21 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 14 Apr 2003 22:27:21 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id PAA02034; Mon, 14 Apr 2003 15:26:24 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma002024; Mon, 14 Apr 03 15:26:16 -0700 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id h3EMQKa27105; Mon, 14 Apr 2003 15:26:20 -0700 (PDT) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id PAA24948; Mon, 14 Apr 2003 15:26:20 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16027.13708.106260.478427@casey.transmeta.com> Date: Mon, 14 Apr 2003 22:27:00 -0000 To: Joel Brobecker Cc: Matt Thomas , gdb@sources.redhat.com Subject: Re: breakpoint commands and finish In-Reply-To: <20030414213340.GJ1151@gnat.com> References: <5.1.1.6.2.20030414135022.04175790@3am-software.com> <20030414210028.GG1151@gnat.com> <20030414210431.GI1151@gnat.com> <16027.9155.65780.337875@casey.transmeta.com> <20030414213340.GJ1151@gnat.com> X-SW-Source: 2003-04/txt/msg00139.txt.bz2 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.