[PATCH] gdb output pipelining to shell

[Abhijit Halder]

Further concern. The last submitted patch does not work in following scenario:
(gdb) p argc | {int} &argc | {vim -}

I think now I should take a pause and refrain myself of doing patch
submission in this thread for some time!

Regards,
Abhijit Halder

On Tue, Jul 19, 2011 at 12:31 AM, Abhijit Halder
<abhijit.k.halder@gmail.com> wrote:
> Since I was overwriting the braces by space character, this could
> essentially change a valid gdb command having braces after pipe.
> Here is the example:
> (gdb) p argc | {int} &argc
>
> I have modified the patch to defer the any overwrite (and essentially
> the modification) of actual input string for very last moment when the
> a sub-string of a given input in gdb prompt is qualified to be in a
> valid format of shell command.
>
> I am re-submitting the patch for review and comments with the
> necessary corrections in place. Please do comment on the changes.
>
>  top.c     |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  ui-file.c |   15 ++++++++++++
>  ui-file.h |    3 ++
>  3 files changed, 94 insertions(+), 1 deletion(-)
>
> Regards,
> Abhijit Halder
>
>
> On Mon, Jul 18, 2011 at 11:31 PM, Abhijit Halder
> <abhijit.k.halder@gmail.com> wrote:
>> Please don't consider this patch. This has a conflict with following
>> syntax of of
>> (gdb) p var | {type} address
>>
>> On Sat, Jul 16, 2011 at 11:35 PM, Abhijit Halder
>> <abhijit.k.halder@gmail.com> wrote:
>>> A small correction. Re-submitting the patch. The earlier patch was not
>>> able to handle below situation:
>>> (gdb) p '|' | { less }
>>>
>>> On Sat, Jul 16, 2011 at 3:38 PM, Abhijit Halder
>>> <abhijit.k.halder@gmail.com> wrote:
>>>> On Sat, Jul 16, 2011 at 3:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>> Date: Sat, 16 Jul 2011 14:12:35 +0530
>>>>>> From: Abhijit Halder <abhijit.k.halder@gmail.com>
>>>>>>
>>>>>> I have implemented a feature which will allow one to pass the output
>>>>>> of any gdb command to the shell for further processing.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> If this is accepted, we will need a corresponding addition to the
>>>>> manual.
>>>>>
>>>>>> +      for (cpos = spos; (cpos = memchr (cpos, '"', (sh_cmd-cpos))) != NULL; cpos++)
>>>>>> +        quote_cnt++;
>>>>>> +      spos = (sh_cmd + 1);
>>>>>> +      if ((quote_cnt % 2) == 0 || (sh_cmd = strchr (spos, '|')) == NULL)
>>>>>> +        break;
>>>>>
>>>>> I'm not sure I understand this (comments would be helpful).  Are you
>>>>> assuming that quote characters `"' in shell commands cannot be
>>>>> escaped, e.g. with a backslash?  And what about quoting with a single
>>>>> quote character ("'")?
>>>>>
>>>> Any pipe ('|' character), not within double quote will be considered
>>>> as either a bitwise-OR operator or a pipe between gdb and shell.
>>>> String after pipe (not within double quote) will be considered as
>>>> shell command if (and only if) it is encapsulated within opening and
>>>> closing braces ('{' and '}') . The shell command can surely contain
>>>> double quote, even braces. There is no validation done for shell
>>>> command.
>>>>
>>>>>> +    if (*cpos != '{')
>>>>>> +      return NULL;
>>>>>> +
>>>>>> +    *cpos = ' ';
>>>>>> +
>>>>>> +    cpos = epos;
>>>>>> +    while (isspace(*cpos))
>>>>>> +      cpos--;
>>>>>> +
>>>>>> +    if (*cpos != '}')
>>>>>> +      return NULL;
>>>>>
>>>>> What is this magic about {...} that you are removing?  Again, comments
>>>>> could help.
>>>>>
>>>> Here I am removing the braces from the shell command. An example will
>>>> help in understanding this:
>>>> (gdb) thread apply all bt | { grep "foo" }
>>>> This will be a valid command. { grep "foo" } will be considered as
>>>> shell command and we need to erase the braces part of it to make it a
>>>> valid shell command.
>>>>>> +
>>>>>> +    *cpos = ' ';
>>>>>> +    }
>>>>>> +
>>>>>> +  if (sh_cmd)
>>>>>> +    *sh_cmd++ = '\0';
>>>>>> +
>>>>>> +  return sh_cmd;
>>>>>
>>>>> This butchers the string passed to execute_command.  Are you sure all
>>>>> the callers of execute_command can safely deal with that?  What if the
>>>>> string is a constant string, for example?
>>>>>
>>>> The new code path will be executed only when one will enter a command
>>>> containing pipeline between gdb and shell. In that case the string
>>>> passed to execute_command must not be a constant string (since it is
>>>> user input from gdb prompt). Hence we are safe.
>>>>
>>>
>>
>