Re: [PATCH] gdb output pipelining to shell

[Abhijit Halder <abhijit dot k dot halder at gmail dot com>]

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.
>>>>
>>>
>>
>