Re: RFC: block of commands

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Mon, 2016-01-11 at 21:40 +0000, Doug Evans wrote:
> Heya.
> 
> One feature I've always wanted gdb's cli to have is the
> ability to catch errors and be able to continue.
> There's always a tension of whether to add things to the cli
> or just say "do it in python". gdb scripts are still useful
> and thus sometimes I think it's ok to extend the cli, such
> as in this case.
> Thus instead of /c in this patch I'd prefer something
> along the lines of "try ... end".
> ["end" is gdb's canonical "trailing }", and I'm all for
> Consistency Is Good here.]
> The actual details and semantics of "try" I would
> leave to a separate thread. For one, I'd have to think
> about it some more :-), but I would support someone
> wanting to go down that path.
> 
> OTOH, trying to extend the cli's syntax with { and ; is not
> something I can support, at least not without more discussion.
> This example:
> 
>      thread apply all { set $prevsp = $sp; bt \{ p $ebp - $prevsp\; set  
> $prevsp = $sp \} }
>        => print the size of each frame
> 
> suggests things could be better; having to escape braces within
> subcommands feels excessively error prone.
> gdb has one line per command, and changing that
> may make things too unwieldly. 
The { (and have the terminating } optional) was chosen in order
to make the interactive typing of a block of command faster/easier.
I agree that this new syntax is very different of the
'usual gdb multi-lines terminated by end'.

However, multi-lines with end means the user cannot simply type e.g.    
   thread apply all { p i; p j}
Instead, the user must type:
   define pij
   p i
   p j
   end
  thread apply all pij
And after, if the user wants to also print k,
then the pij sequence must be retyped (I do not know a way
to change/edit/complete a user defined command).

An alternative might be to make the terminating } mandatory.
Then I think we could get rid of the { and } escaping

So, the question is how much we want to make the block of commands
easy to use interactively ?

Maybe it is not that unusual to have 2 concepts
of 'list of commands' :
    one command per line, with some 'begin/end' keywords
   several commands per lines, separated by ;
(i.e. similar to what a shell is providing with if/fi and ;).

The ; separated list versus multi-lines is clearly the main
point of discussion.

Note that if ever the {}; idea survives, we have to take care
about parsing of existing scripts that would do e.g.
   echo { is an open bracket
Not too sure it will be easy to make the {}; idea fully backward
compatible :(

> There are still
> macros so one could still do "thread apply all print-frame-size",
> and put the guts of frame size computation in a macro named
> print-frame-size.
True, but that makes the interactive use and editing
not so easy (cfr above).

> 
> Also, I'd prefer to have generally composable commands
> over extending individual commands.
> E.g., one common thing to do with "thread apply" is backtrace,
> as in "thread apply all bt". I like that much better than
> if we had extended backtrace to work on each thread.
> 
> Following "Consistency Is Good", and given that we have
> "thread apply", for your "bt {/c p i" case how about
> something like:
> 
> frame apply all foo
Yes, that looks better than adding an optional command to
backtrace.


Philippe