Hi Dave, On Tue, Feb 21, 2012 at 12:34 PM, Dave Anderson <anderson@xxxxxxxxxx> wrote: > I'm not sure what you mean about the "open parenthesis", but I think I looked at "expression" handling. Once an open parenthesis is recognized, the scanner goes into "expression" mode and leaves that mode when a closing parenthesis is encountered. Since the expression includes nested parentheses, that means that whatever it is that "expression" state means must, perforce, be confused after encountering the first of two closing parentheses. That's a kind-of verbose description, so I hope its clear. > this simpler example shows the problem, which is related to using > a native gdb command in conjunction with a pipe and a redirect. > > The "p" command is sort of a "convenience" crash command that pretty > much exists to be able to quickly change the output radix before passing > the request to the gdb module. I got that much out of it. I figured (without code reading) that the entire command line would be more-or-less passed on directly to the GDB interpreter without much muss or fuss on crash's part. Obviously wrong. > Piping the output works: > > crash> px jiffies | cat > jiffies = $14 = 0xfffcc009 > crash> > > Piping the output, and then redirecting it works: > > crash> px jiffies | cat > /tmp/junk > crash> !cat /tmp/junk > jiffies = $15 = 0xfffcc009 > crash> > > But using the gdb "p/x" command directly (bypassing the crash "p" > command), in conjunction with a pipe and a redirect, generates the > failure. Just a pipe or a redirect alone works OK: Yep. That was what I noticed. I really do think that the redirection code needs to be thought over a bit more. Another problem I discovered while creating 100's to 1000's of ``crash-cmd | shell-cmd >> outfile'' thingys was that the pipe would occasionally hiccup. That hiccup would put a really nasty belch into the "outfile" that was impossible to accommodate. In the end, my new paradigm is: crash-cmd > unique-file-name and when they're all done, run some code that fiddles with each of these gazillion files, none of which will contain command trace output nor error messages. They will all go to the correct FD. I think command tracing needs to be done before command output redirection and I think that error reporting needs to happen on an error reporting fd (e.g. stderr). Meanwhile, I'll just use gazillions of files. > Not sure why just yet, other than there's a difference in the way > native gdb commands and crash commands are processed. Let me dig > into it... OK, thank you. I'd likely be easier if you just scanned the input line for an end-of-crash-command mark (redirection or pipe) and the code wrapping the gdb commands would never need to know anything about what happens after the '|' or '>' character, or even that there was one. That was probably your intent and something got in the way..... Cheers - Bruce -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility