This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 0/4] Improve "show style", use style in "help" and "apropos".


On Tue, 2019-06-18 at 23:40 +0100, Pedro Alves wrote:
> On 6/18/19 9:57 PM, Philippe Waroquiers wrote:
> > > Wondering ...
> > > 
> > > At shell level, coloring seems to be disabled when piped.
> > > E.g.  
> > >   $ ls -l
> > >   .... files with some colors
> > >   $ ls -l | cat
> > >   .... same output, but no colors
> > >   $
> > 
> > ls has an option to control coloring.
> >    ls -l --color=always|cat
> > will still be colored.
> > 
> > So, we might add an option -style [on|off] to the GDB pipe_command,
> > if we believe it should output styling sequence.
> 
> Agreed.
> 
> In other words, this would let us pipe with style.  :-D
> 
> In addition, "set style enabled" could be made an auto-boolean
> setting, with default "auto", enable styling iff outputting to
> a terminal.  Then, "on" would force styling even if outputting
> to a pipe.  This would let you force styling with:
> 
>  (gdb) with style enabled on -- | apropos -v breakpoint | less

When we have this 'set style enabled auto|on|off',
wondering if the user will often have to override the behavior
in the pipe command:
The global setting will be enough for most of the users,
and the 'with' command should be good enough for the
unfrequent need to override styling for the pipe command.


Note that I am envisaging to do a small addition
to the 'define' command so as to make it slightly
easier to write a 'define wrapper shortcut' around
a 'with command'.

Something like:
define Lc
  with language c -- $arg@
end
document Lc
  Usage: Lc [COMMAND [ARGS]...]
  Shortcut for:
     with language c -- [COMMAND [ARGS]...]
end

This new '$arg@' will allow a user (like me) that
prefers to type as little as possible to define
very small shortcuts for often used 'with commands',
without expanding all arguments inside the 'define'
command with a bunch of 'if's depending on $argc.

Note that interactively, the 'with' command
combines properly with the 'if' command.

But the 'define' parser seems to not understand that
a 'with' line can start an 'if' that needs a
corresponding 'end'.

In other words, interactively, the below works
(gdb) with language c -- if $xxx == 0
 >echo zero\n
 >else
 >echo not zero\n
 >end
zero
(gdb) 

but inside a 'define', the parser does not understand
the above:

(gdb) define nnnn
Type commands for definition of "nnnn".
End with a line saying just "end".
>with language c -- if $xxx == 0
>echo zero\n
>else
(gdb) show user nnnn
User command "nnnn":
(gdb) 

Maybe worth adding a 'mini with command' detector/parser
in the 'define' parser, so as to allow user defined
commands to be less dependent of the current language
when evaluating expressions.

Alternatively, we should allow alias to accept 'arguments':
Instead of:
   (gdb) alias Lc = with language c --
   Invalid command to alias to: with language c --
   (gdb)
GDB should do:
   (gdb) alias Lc = with language c --
   => Defined Lc as an alias of 'with' command, using prefix args 'language c --'
   (gdb)
and then
   (gdb) Lc somecommand somearg someotherarg
should be the equivalent of:
   (gdb) with language c -- somecommand somearg someotherarg

No idea if the above is easy to do.

I have in a corner a patch that allows to add default arguments to
a command or an alias, which gives more or less the above, but using
2 successive actions:
  (gdb) alias bt2 = bt
  (gdb) help add-args 
  Specify additional arguments to preprend to user provided command arguments.
  Usage:  add-args COMMAND [= ADDITIONAL_ARGS...]
  Allows to specify or clear the additional arguments automatically
  prepended to the user provided arguments when COMMAND is run.
  Note that COMMAND can be an alias.  Aliases and their aliased commands
  do not share their additional arguments, so you can specify different
  additional arguments for a command and for each of its aliases.
  Without the [= ADDITIONAL_ARGS...], clears COMMAND additional arguments.
  (gdb) add-args bt2 = 2
  (gdb) bt2
  #0  0x00007ffff78fe603 in select () at ../sysdeps/unix/syscall-template.S:84
  #1  0x0000555555554f5e in sleeper_or_burner (v=0x7fffffffdf30) at sleepers.c:86
  (More stack frames follow...)
  (gdb) 

(add-args allows to implement Lc and similar, but also allows
a user to specify 'default' arguments for any command (or alias).
So, maybe I should finalize an RFA for this add-args idea in preference
to the 'alias argument idea' and/or to the '$arg@' idea.

Also maybe 'alias xxx = somecommand someargs'
can just be a fast way to type:
     alias xxx = somecommand
     add-args xxx = someargs

Too many ideas, too little time ... :(

Philippe

NB: the above discussion can be summarized as
   'the return of the slash command abbreviations for those that liked them' :)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]