PATCH

PATCH

[Abhijit Halder]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

There is no way to pass the output of a gdb command to a shell
command. For example, something similar is not permitted: "(gdb)
thread apply all bt | vim -". This kind of feature is quite helpful in
a scenario where a program under debugger has 100s of threads running
and one wants to search a particular pattern in stack-traces. I have
implemented a feature which will allow one to pass the output of any
gdb command to any shell command.

2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>

    * top.c (execute_command_to_pipe): New function.
     (execute_command): Update.
    * ui-file.c (gdb_modify_io): New function.
    * ui-file.h (gdb_modify_io): Add prototype.

[-- Attachment #2: gdb-enhancement.patch --]
[-- Type: text/x-patch, Size: 2620 bytes --]

diff -rup src//gdb/top.c dst//gdb/top.c
--- src//gdb/top.c	2011-06-28 00:51:50.000000000 +0530
+++ dst//gdb/top.c	2011-07-09 13:11:57.480044436 +0530
@@ -48,6 +48,7 @@
 #include "event-loop.h"
 #include "gdbthread.h"
 #include "python/python.h"
+#include "ui-file.h"
 
 /* readline include files.  */
 #include "readline/readline.h"
@@ -358,6 +359,20 @@ prepare_execute_command (void)
   return cleanup;
 }
 
+
+/* Run execute_command for P and FROM_TTY. Write output in pipe, 
+   do not display it to the screen.  */
+
+void
+execute_command_to_pipe (char *p, int from_tty, FILE *pipe)
+{
+  FILE *file;
+  
+  file = gdb_modify_io (gdb_stdout, pipe);
+  execute_command (p, from_tty);
+  pipe = gdb_modify_io (gdb_stdout, file);
+  pclose (pipe);
+}
 /* Execute the line P as a command, in the current user context.
    Pass FROM_TTY as second argument to the defining function.  */
 
@@ -368,7 +383,16 @@ execute_command (char *p, int from_tty)
   struct cmd_list_element *c;
   enum language flang;
   static int warned = 0;
-  char *line;
+  char *line, *sh_cmd;
+
+  if ((sh_cmd = strchr(p,'|')) != NULL) 
+    {
+      FILE *pipe;
+      *sh_cmd++ = '\0';
+      pipe = popen (sh_cmd, "w");
+      execute_command_to_pipe (p, from_tty, pipe);
+      return;
+    }
 
   cleanup = prepare_execute_command ();
 
diff -rup src//gdb/ui-file.c dst//gdb/ui-file.c
--- src//gdb/ui-file.c	2011-05-14 11:14:36.000000000 +0530
+++ dst//gdb/ui-file.c	2011-07-09 13:16:50.404045208 +0530
@@ -617,6 +617,21 @@ struct ui_file *
 stdio_fileopen (FILE *file)
 {
   return stdio_file_new (file, 0);
+
+}
+
+FILE *
+gdb_modify_io (struct ui_file *file, FILE *iostream_new)
+{
+  FILE *iostream_old;
+  struct stdio_file *stdio = ui_file_data (file);
+
+  if (stdio->magic != &stdio_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    _("stdio_file_flush: bad magic number"));
+  iostream_old = stdio->file;
+  stdio->file = iostream_new;
+  return iostream_old;
 }
 
 struct ui_file *
diff -rup src//gdb/ui-file.h dst//gdb/ui-file.h
--- src//gdb/ui-file.h	2011-05-13 22:58:20.000000000 +0530
+++ dst//gdb/ui-file.h	2011-07-09 13:14:21.484044803 +0530
@@ -126,6 +126,9 @@ extern struct ui_file *stdio_fileopen (F
 /* Open NAME returning an STDIO based UI_FILE.  */
 extern struct ui_file *gdb_fopen (char *name, char *mode);
 
+/* Modify the file pointer of an STDIO based UI_FILE. */
+FILE *gdb_modify_io (struct ui_file *file, FILE *iostream_new);
+
 /* Create a file which writes to both ONE and TWO.  CLOSE_ONE
    and CLOSE_TWO indicate whether the original files should be
    closed when the new file is closed.  */

Re: PATCH

[oza Pawandeep]

Hi,

with tee command, or similar things you can always redirect output to
file, and from there you may apply the script to get output from that.
probably use source command to automate and use shell command to run
the script to get the things done.
sure your way just gets output instantly, but other than that what
value does it add; I am trying to understand.

Regards,
Oza.

On Sat, Jul 9, 2011 at 2:00 PM, Abhijit Halder
<abhijit.k.halder@gmail.com> wrote:
> There is no way to pass the output of a gdb command to a shell
> command. For example, something similar is not permitted: "(gdb)
> thread apply all bt | vim -". This kind of feature is quite helpful in
> a scenario where a program under debugger has 100s of threads running
> and one wants to search a particular pattern in stack-traces. I have
> implemented a feature which will allow one to pass the output of any
> gdb command to any shell command.
>
> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
>
>    * top.c (execute_command_to_pipe): New function.
>     (execute_command): Update.
>    * ui-file.c (gdb_modify_io): New function.
>    * ui-file.h (gdb_modify_io): Add prototype.
>

Re: PATCH

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 638 bytes --]

On Saturday, July 09, 2011 04:30:29 Abhijit Halder wrote:
> There is no way to pass the output of a gdb command to a shell
> command. For example, something similar is not permitted: "(gdb)
> thread apply all bt | vim -". This kind of feature is quite helpful in
> a scenario where a program under debugger has 100s of threads running
> and one wants to search a particular pattern in stack-traces. I have
> implemented a feature which will allow one to pass the output of any
> gdb command to any shell command.

looks pretty cool.  your e-mail summaries in the future though should be more 
clear than simply "PATCH".
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PATCH

[Abhijit Halder]

Yes, you are right. But to run a shell script you have to either quit
from gdb session or you have to run shell command to get a shell. In
first choice the analysis of debug information is offline that may not
be acceptable in certain situation where you take certain decision
based on your debug information. In second choice you every time get a
shell you source your shell profile (like bashrc bash_profile) that is
not acceptable.
Finally, the method you suggested will dump all the debug info in a
file (this sometimes annoying). Processing that big file will again
consumes more resources.

On Sat, Jul 9, 2011 at 6:39 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Hi,
>
> with tee command, or similar things you can always redirect output to
> file, and from there you may apply the script to get output from that.
> probably use source command to automate and use shell command to run
> the script to get the things done.
> sure your way just gets output instantly, but other than that what
> value does it add; I am trying to understand.
>
> Regards,
> Oza.
>
> On Sat, Jul 9, 2011 at 2:00 PM, Abhijit Halder
> <abhijit.k.halder@gmail.com> wrote:
>> There is no way to pass the output of a gdb command to a shell
>> command. For example, something similar is not permitted: "(gdb)
>> thread apply all bt | vim -". This kind of feature is quite helpful in
>> a scenario where a program under debugger has 100s of threads running
>> and one wants to search a particular pattern in stack-traces. I have
>> implemented a feature which will allow one to pass the output of any
>> gdb command to any shell command.
>>
>> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
>>
>>    * top.c (execute_command_to_pipe): New function.
>>     (execute_command): Update.
>>    * ui-file.c (gdb_modify_io): New function.
>>    * ui-file.h (gdb_modify_io): Add prototype.
>>
>

Re: PATCH

[Abhijit Halder]

Yes, you are right. But to run a shell script you have to either quit
from gdb session or you have to run shell command to get a shell. In
first choice the analysis of debug information is offline that may not
be acceptable in certain situation where you take certain decision
based on your debug information. In second choice you every time get a
shell you source your shell profile (like bashrc bash_profile) that is
not acceptable.
Finally, the method you suggested will dump all the debug info in a
file (this sometimes annoying). Processing that big file will again
consumes more resources.

On Sat, Jul 9, 2011 at 6:39 PM, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> Hi,
>
> with tee command, or similar things you can always redirect output to
> file, and from there you may apply the script to get output from that.
> probably use source command to automate and use shell command to run
> the script to get the things done.
> sure your way just gets output instantly, but other than that what
> value does it add; I am trying to understand.
>
> Regards,
> Oza.
>
> On Sat, Jul 9, 2011 at 2:00 PM, Abhijit Halder
> <abhijit.k.halder@gmail.com> wrote:
>> There is no way to pass the output of a gdb command to a shell
>> command. For example, something similar is not permitted: "(gdb)
>> thread apply all bt | vim -". This kind of feature is quite helpful in
>> a scenario where a program under debugger has 100s of threads running
>> and one wants to search a particular pattern in stack-traces. I have
>> implemented a feature which will allow one to pass the output of any
>> gdb command to any shell command.
>>
>> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
>>
>>    * top.c (execute_command_to_pipe): New function.
>>     (execute_command): Update.
>>    * ui-file.c (gdb_modify_io): New function.
>>    * ui-file.h (gdb_modify_io): Add prototype.
>>
>

Re: PATCH

[Tom Tromey]

>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:

Abhijit> There is no way to pass the output of a gdb command to a shell
Abhijit> command. For example, something similar is not permitted: "(gdb)
Abhijit> thread apply all bt | vim -". This kind of feature is quite helpful in
Abhijit> a scenario where a program under debugger has 100s of threads running
Abhijit> and one wants to search a particular pattern in stack-traces. I have
Abhijit> implemented a feature which will allow one to pass the output of any
Abhijit> gdb command to any shell command.

It would be nice to be able to do something like this.

Abhijit> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
Abhijit>     * top.c (execute_command_to_pipe): New function.
Abhijit>      (execute_command): Update.

I don't think this implementation is the right approach.
It does the wrong thing with some existing valid commands, e.g. "print x|5".

Tom

Re: PATCH

[Abhijit Halder]

Yes I missed it. Let me modify the implementation to achieve the goal.

On Tue, Jul 12, 2011 at 1:17 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:
>
> Abhijit> There is no way to pass the output of a gdb command to a shell
> Abhijit> command. For example, something similar is not permitted: "(gdb)
> Abhijit> thread apply all bt | vim -". This kind of feature is quite helpful in
> Abhijit> a scenario where a program under debugger has 100s of threads running
> Abhijit> and one wants to search a particular pattern in stack-traces. I have
> Abhijit> implemented a feature which will allow one to pass the output of any
> Abhijit> gdb command to any shell command.
>
> It would be nice to be able to do something like this.
>
> Abhijit> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
> Abhijit>     * top.c (execute_command_to_pipe): New function.
> Abhijit>      (execute_command): Update.
>
> I don't think this implementation is the right approach.
> It does the wrong thing with some existing valid commands, e.g. "print x|5".
>
> Tom
>

Re: PATCH

[Abhijit Halder]

How if we just put a condition check whether the entered string after
pipe (|) is numeric. For e.g.
(gdb) thread apply all bt | grep foobar
Here the entered string after | is grep foobar which is not numeric.
But here (gdb) print var | 0x50 is numeric.

We may safely use this above notion as in case of any numeric file
name can be encapsulated within quote.

Soon I will submit the updated patch. Please provide feedback on this.

On Tue, Jul 12, 2011 at 5:01 AM, Abhijit Halder
<abhijit.k.halder@gmail.com> wrote:
> Yes I missed it. Let me modify the implementation to achieve the goal.
>
> On Tue, Jul 12, 2011 at 1:17 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:
>>
>> Abhijit> There is no way to pass the output of a gdb command to a shell
>> Abhijit> command. For example, something similar is not permitted: "(gdb)
>> Abhijit> thread apply all bt | vim -". This kind of feature is quite helpful in
>> Abhijit> a scenario where a program under debugger has 100s of threads running
>> Abhijit> and one wants to search a particular pattern in stack-traces. I have
>> Abhijit> implemented a feature which will allow one to pass the output of any
>> Abhijit> gdb command to any shell command.
>>
>> It would be nice to be able to do something like this.
>>
>> Abhijit> 2011-07-09 Abhijit Halder <abhijit.k.halder@symantec.com>
>> Abhijit>     * top.c (execute_command_to_pipe): New function.
>> Abhijit>      (execute_command): Update.
>>
>> I don't think this implementation is the right approach.
>> It does the wrong thing with some existing valid commands, e.g. "print x|5".
>>
>> Tom
>>
>

Re: PATCH

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1033 bytes --]

On Tuesday, July 12, 2011 00:24:15 Abhijit Halder wrote:

please do not top post in your replies

> How if we just put a condition check whether the entered string after
> pipe (|) is numeric. For e.g.
> (gdb) thread apply all bt | grep foobar
> Here the entered string after | is grep foobar which is not numeric.
> But here (gdb) print var | 0x50 is numeric.

that wont work as it's "EXPR | EXPR".  so you could do:
(gdb) print x | x

or if your variable was named "vim", it's impossible to determine the user's 
intention if they wrote something like:
(gdb) print x | vim
do they want the variable "vim" ?  or do they want to shell out to `vim` ?

i think we'll have to introduce a dedicated operator here that doesn't show up 
in C expressions.  how about "|&" ?  this is a bashism for doing 
redirection+pipe in one go, so it'll be somewhat familiar to people.

along those lines, i wonder if generic redirection operators would be useful 
too.  something like:
(gdb) thread apply all bt >& file
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: PATCH

[Abhijit Halder]

Yes Mike. I am really sorry for this silly post made in hurry. Yes
since the pipe (|) symbol is also a c operator, it will confuse gdb.
Even if we use |& we may land up into a trouble situation.

Breakpoint 1, main (argc=1, argv=0x7fffb6e506a8) at test.c:15
15          return (SUCCESS) ;
(gdb) p argc|&*argc
$1 = 1
(gdb) p argc |& *argc
$2 = 1
(gdb)



On Tue, Jul 12, 2011 at 10:47 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday, July 12, 2011 00:24:15 Abhijit Halder wrote:
>
> please do not top post in your replies
>
>> How if we just put a condition check whether the entered string after
>> pipe (|) is numeric. For e.g.
>> (gdb) thread apply all bt | grep foobar
>> Here the entered string after | is grep foobar which is not numeric.
>> But here (gdb) print var | 0x50 is numeric.
>
> that wont work as it's "EXPR | EXPR".  so you could do:
> (gdb) print x | x
>
> or if your variable was named "vim", it's impossible to determine the user's
> intention if they wrote something like:
> (gdb) print x | vim
> do they want the variable "vim" ?  or do they want to shell out to `vim` ?
>
> i think we'll have to introduce a dedicated operator here that doesn't show up
> in C expressions.  how about "|&" ?  this is a bashism for doing
> redirection+pipe in one go, so it'll be somewhat familiar to people.
>
> along those lines, i wonder if generic redirection operators would be useful
> too.  something like:
> (gdb) thread apply all bt >& file
> -mike
>

Re: PATCH

[Mike Frysinger]

On Tue, Jul 12, 2011 at 03:15, Abhijit Halder wrote:

please dont top post in your replies

> Yes Mike. I am really sorry for this silly post made in hurry.

no need to apologize ... this is what code review is for

> since the pipe (|) symbol is also a c operator, it will confuse gdb.
> Even if we use |& we may land up into a trouble situation.
>
> Breakpoint 1, main (argc=1, argv=0x7fffb6e506a8) at test.c:15
> 15          return (SUCCESS) ;
> (gdb) p argc|&*argc
> $1 = 1
> (gdb) p argc |& *argc
> $2 = 1
> (gdb)

i'm not seeing this.  on an unmodified gdb-7.2, i get:
(gdb) p g
$1 = 0xa
(gdb) p g |& g
Argument to arithmetic operation not a number or boolean.

so what am i missing ?
-mike

Re: PATCH

[Matt Rice]

On Tue, Jul 12, 2011 at 8:59 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tue, Jul 12, 2011 at 03:15, Abhijit Halder wrote:
>
> please dont top post in your replies
>
>> Yes Mike. I am really sorry for this silly post made in hurry.
>
> no need to apologize ... this is what code review is for
>
>> since the pipe (|) symbol is also a c operator, it will confuse gdb.
>> Even if we use |& we may land up into a trouble situation.
>>
>> Breakpoint 1, main (argc=1, argv=0x7fffb6e506a8) at test.c:15
>> 15          return (SUCCESS) ;
>> (gdb) p argc|&*argc
>> $1 = 1
>> (gdb) p argc |& *argc
>> $2 = 1
>> (gdb)
>
> i'm not seeing this.  on an unmodified gdb-7.2, i get:
> (gdb) p g
> $1 = 0xa
> (gdb) p g |& g
> Argument to arithmetic operation not a number or boolean.
>
> so what am i missing ?
> -mike
>

this one should work.

p 0 |& argv[argc] - &argv[0]

Re: PATCH

[Mike Frysinger]

On Tue, Jul 12, 2011 at 13:31, Matt Rice wrote:
> On Tue, Jul 12, 2011 at 8:59 AM, Mike Frysinger wrote:
>> On Tue, Jul 12, 2011 at 03:15, Abhijit Halder wrote:
>>> since the pipe (|) symbol is also a c operator, it will confuse gdb.
>>> Even if we use |& we may land up into a trouble situation.
>>>
>>> Breakpoint 1, main (argc=1, argv=0x7fffb6e506a8) at test.c:15
>>> 15          return (SUCCESS) ;
>>> (gdb) p argc|&*argc
>>> $1 = 1
>>> (gdb) p argc |& *argc
>>> $2 = 1
>>> (gdb)
>>
>> i'm not seeing this.  on an unmodified gdb-7.2, i get:
>> (gdb) p g
>> $1 = 0xa
>> (gdb) p g |& g
>> Argument to arithmetic operation not a number or boolean.
>>
>> so what am i missing ?
>
> this one should work.
>
> p 0 |& argv[argc] - &argv[0]

oh, i see now.  creative spacing.  "...|& FOO" is taking the address
of FOO.  hrm, this would also mean ">&" wont work as that could be a
comparison against the address of a variable.

">|" might work.  it's not as intuitive, but it's muscle memory in the
end and people will learn soon enough :P.
-mike

Re: PATCH

[Tom Tromey]

>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:

Abhijit> How if we just put a condition check whether the entered string after
Abhijit> pipe (|) is numeric. [...]

(This was dealt with, but I just wanted to find a decent spot to insert
a reply.)

I was too terse yesterday.  The big problem with any generic approach is
that GDB syntax is free-form: each command defines its own syntax.  So,
for any syntax you think up, there is a decent chance that it already
means something to some command, or could.

This doesn't mean it is impossible, just difficult.

We already have "set logging".  This isn't as convenient to use, but it
could certainly be extended to allow pipes.

There is also at least one PR about this in bugzilla.

Tom

Re: PATCH

[Mike Frysinger]

On Tue, Jul 12, 2011 at 15:25, Tom Tromey wrote:
>>>>>> "Abhijit" == Abhijit Halder writes:
> Abhijit> How if we just put a condition check whether the entered string after
> Abhijit> pipe (|) is numeric. [...]
>
> I was too terse yesterday.  The big problem with any generic approach is
> that GDB syntax is free-form: each command defines its own syntax.  So,
> for any syntax you think up, there is a decent chance that it already
> means something to some command, or could.
>
> This doesn't mean it is impossible, just difficult.

i was also pondering reversing the order.  rather than being a suffix
that gets mucked up in syntax, add a pass through.  but that too can
get ugly.

pipe <command to pipe into> <normal command> <command args>
(gdb) pipe "vim -" thread apply all bt

> We already have "set logging".  This isn't as convenient to use, but it
> could certainly be extended to allow pipes.

when i thought of a secondary command, i think half the power of what
Abhijit proposes is having it in a single command.  especially when
shell scripting is all about slightly tweaking the command and looking
at the result.  that way you dont keep flipping between the two -- one
to update the command to pipe into, and two to update the stuff you're
piping out.
-mike

Re: PATCH

[Abhijit Halder]

Just a quick thought. How if we can do something like this:

(gdb) gdb_command_with_arguments |  "shell_command_with_argument"

Since pipe (|) as c operator will never expect any rvalue within
string, we are safe. We just have to ensure that odd number of
double-quote (") not present before (left-side of) the pipe to
safe-guard a case like below.

(gdb) p "Hi | Bye"

Further, the shell command may itself contain double-quote. We have to
allow nested double-quote.

(gdb) thread apply all bt | " grep "foobar" "


On Wed, Jul 13, 2011 at 2:00 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tue, Jul 12, 2011 at 15:25, Tom Tromey wrote:
>>>>>>> "Abhijit" == Abhijit Halder writes:
>> Abhijit> How if we just put a condition check whether the entered string after
>> Abhijit> pipe (|) is numeric. [...]
>>
>> I was too terse yesterday.  The big problem with any generic approach is
>> that GDB syntax is free-form: each command defines its own syntax.  So,
>> for any syntax you think up, there is a decent chance that it already
>> means something to some command, or could.
>>
>> This doesn't mean it is impossible, just difficult.
>
> i was also pondering reversing the order.  rather than being a suffix
> that gets mucked up in syntax, add a pass through.  but that too can
> get ugly.
>
> pipe <command to pipe into> <normal command> <command args>
> (gdb) pipe "vim -" thread apply all bt
>
>> We already have "set logging".  This isn't as convenient to use, but it
>> could certainly be extended to allow pipes.
>
> when i thought of a secondary command, i think half the power of what
> Abhijit proposes is having it in a single command.  especially when
> shell scripting is all about slightly tweaking the command and looking
> at the result.  that way you dont keep flipping between the two -- one
> to update the command to pipe into, and two to update the stuff you're
> piping out.
> -mike
>

Re: PATCH

[Abhijit Halder]

Hi,

I have made the changes to handle following cases. Should I re-submit
the new patch in the same thread, or I change the subject line (as it
does not reveal much the problem definition) and re-submit the patch
in a new thread?

On Wed, Jul 13, 2011 at 12:39 PM, Abhijit Halder
<abhijit.k.halder@gmail.com> wrote:
> Just a quick thought. How if we can do something like this:
>
> (gdb) gdb_command_with_arguments |  "shell_command_with_argument"
>
> Since pipe (|) as c operator will never expect any rvalue within
> string, we are safe. We just have to ensure that odd number of
> double-quote (") not present before (left-side of) the pipe to
> safe-guard a case like below.
>
> (gdb) p "Hi | Bye"
>
> Further, the shell command may itself contain double-quote. We have to
> allow nested double-quote.
>
> (gdb) thread apply all bt | " grep "foobar" "
>
>
> On Wed, Jul 13, 2011 at 2:00 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Tue, Jul 12, 2011 at 15:25, Tom Tromey wrote:
>>>>>>>> "Abhijit" == Abhijit Halder writes:
>>> Abhijit> How if we just put a condition check whether the entered string after
>>> Abhijit> pipe (|) is numeric. [...]
>>>
>>> I was too terse yesterday.  The big problem with any generic approach is
>>> that GDB syntax is free-form: each command defines its own syntax.  So,
>>> for any syntax you think up, there is a decent chance that it already
>>> means something to some command, or could.
>>>
>>> This doesn't mean it is impossible, just difficult.
>>
>> i was also pondering reversing the order.  rather than being a suffix
>> that gets mucked up in syntax, add a pass through.  but that too can
>> get ugly.
>>
>> pipe <command to pipe into> <normal command> <command args>
>> (gdb) pipe "vim -" thread apply all bt
>>
>>> We already have "set logging".  This isn't as convenient to use, but it
>>> could certainly be extended to allow pipes.
>>
>> when i thought of a secondary command, i think half the power of what
>> Abhijit proposes is having it in a single command.  especially when
>> shell scripting is all about slightly tweaking the command and looking
>> at the result.  that way you dont keep flipping between the two -- one
>> to update the command to pipe into, and two to update the stuff you're
>> piping out.
>> -mike
>>
>

Re: PATCH

[Tom Tromey]

>>>>> "Abhijit" == Abhijit Halder <abhijit.k.halder@gmail.com> writes:

Abhijit> I have made the changes to handle following cases. Should I re-submit
Abhijit> the new patch in the same thread, or I change the subject line (as it
Abhijit> does not reveal much the problem definition) and re-submit the patch
Abhijit> in a new thread?

Either way is fine.

Tom

Re: PATCH

[Sergio Durigan Junior]

Abhijit Halder <abhijit.k.halder@gmail.com> writes:

> I have made the changes to handle following cases. Should I re-submit
> the new patch in the same thread, or I change the subject line (as it
> does not reveal much the problem definition) and re-submit the patch
> in a new thread?

Hello Abhijit,

As Tom said, either way is fine.  Also, please don't do top-posting when
replying e-mails, i.e., don't reply on top of the other messages.  We
prefer this style:

       http://en.wikipedia.org/wiki/Posting_style#Interleaved_style

Please use it when you are replying to mailing lists in general.

Thank you.

gdb output pipelining to shell (was: Re: PATCH)

[Pedro Alves]

On Tuesday 12 July 2011 21:30:00, Mike Frysinger wrote:
> On Tue, Jul 12, 2011 at 15:25, Tom Tromey wrote:
> >>>>>> "Abhijit" == Abhijit Halder writes:
> > Abhijit> How if we just put a condition check whether the entered string after
> > Abhijit> pipe (|) is numeric. [...]
> >
> > I was too terse yesterday.  The big problem with any generic approach is
> > that GDB syntax is free-form: each command defines its own syntax.  So,
> > for any syntax you think up, there is a decent chance that it already
> > means something to some command, or could.
> >
> > This doesn't mean it is impossible, just difficult.
> 
> i was also pondering reversing the order.  rather than being a suffix
> that gets mucked up in syntax, add a pass through.  but that too can
> get ugly.
> 
> pipe <command to pipe into> <normal command> <command args>
> (gdb) pipe "vim -" thread apply all bt

Another option would be to still have a normal order pipe
command, and have the user specify the splitting character,
kind of like a grandchild of sed's s/// vs s,,, etc, and 
cat EOF pattern.  So, you'd have:

  pipe SPLITTER_TOKEN

the usual | would work:

 (gdb) pipe | bt | vim -

if necessary due to conflict, use a different token:

 (gdb) pipe , p 1 | 2 , vim -

or:

 (gdb) pipe PIPE p 1 | 2 PIPE vim -

etc.

WDYT?

I think I like this better than comming up with some
syntax that we need to make sure works not just with C,
but all supported languages.  (and hope no future supported
language adds a conflict).

We can tweak the syntax a bit to support
options to the pipe command.  E.g, define that
the pipe command always ends with a lone '-' before
the gdb command chain, and -t for pipe token, then:

No -t switch, assume `|' pipe token:

 (gdb) pipe - bt | vim -

Specify alternate pipe token:

 (gdb) pipe -t PIPE - p 1 | 2 PIPE vim -

Pass some other option to `pipe':

 (gdb) pipe --some-option - bt | vim -

-- 
Pedro Alves