DEBUG_CMD_LINE (Was Re: PATCH: skip command from debug trap)

["Rocky Bernstein" <rocky.bernstein@gmail.com>]

On Wed, Aug 6, 2008 at 3:49 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> "Rocky Bernstein" wrote:
>> But given the choice of adding
>>    1) an option in the return statement everywhere that is specific to
>> just "trap DEBUG" or
>>    2) specifying what specific numbers do when on a return from "trap DEBUG",
>>
>> isn't 2) simpler and more consistent with programming in shell
>> languages work? I take it as a given that every function or command is
>> going to have error codes that are somewhat arbitrary and that I'm not
>> going to intuit.
>
> I'm in two minds about this.

Ok. I'm sure you'll do what's best and let us know what is decided.

> If we didn't have the existing rule that
> any non-zero return status from TRAPDEBUG, or any explicit return from
> within an inline trap, forced an immediate return, then I'd agree simply
> adding to the set of useful statuses was cleaner and more natural.  As
> it is, we're now forced to pick some numeric value the user wouldn't
> naturally want to return from am enclosing context (since the return
> value is propagated).
>
> The option to return seems to me natural enough, because as "return"
> means "just return", so "return with an option" means "return but with
> slightly different semantics".  Having a different return status meaning
> to execute different code (rather than simply provide a different test
> for the caller, as normal) is an unusual enough effect that it doesn't
> strike me as the unequivocal answer.
>
> But, whatever.  If there's a number we all really like to mean "skip",
> we can go with that.  It's already working, is easy to document, and
> doesn't need any changes to parsing.
>
> (By the way, it wouldn't be too hard, if not completely trivial, to pass
> down the code about to be executed in a variable, say DEBUG_CMD_LINE, as
> reconstructed text, i.e. the same sort of format as what you get if you
> get the shell to output a shell function that's already loaded.  But
> it's messy enough that I won't unless it's definitely useful.)

My secret plan was to get the debugger working enough for folks to realize this
would be useful. In bash the variable $BASH_COMMAND holds the command that
is up for execution next. It is not the "line"  (as suggested in the
name DEBUG_CMD_LINE)
 but the last command or statement.

And  although DEBUG_CMD_LINE can be used in debugging, there's nothing
about it that
strictly needs to be so. For example suppose I wanted to get statistics on how
many commands are run that start with the letter A.

Anyway, in debugging where it's most useful are places where there are
statement
lines for example

   [[ -z $FOO ]] && bar || baz
   temp=x; x=y; y=temp

If one is is stepping along it can be useful to know in which part of
the line you
are about to run. The hueristic that bashdb uses is that if the line
number is the
same as the last line number that it stopped at but the command string changes,
then it's probably a good idea to show not just the line but also the command
that is about to be executed. In practice this means that one can assume that
whenever you see a line with more than one statement and no statement is
explicitly printed, then one can assume that the statement that is about to be
run is the first one shown. And if one is not sure one can just run a
print $BASH_COMMAND
debugger command.

>
> --
> Peter Stephenson <p.w.stephenson@ntlworld.com>
> Web page now at http://homepage.ntlworld.com/p.w.stephenson/
>