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