I really like to use the x command in crash, as in: crash-4.0.9> x/256xg 0xffff8801aa9c8000 0xffff8801aa9c8000: 0xffff8800c61541c0 0xffff880145a194c0 0xffff8801aa9c8010: 0xffff88016fa481c0 0xffff88016c7980c0 ... I like it better than the rd command (because of prior familiarity perhaps?): crash-4.0.9> rd -x -64 0xffff8801aa9c8000 256 ffff8801aa9c8000: ffff8800c61541c0 ffff880145a194c0 ffff8801aa9c8010: ffff88016fa481c0 ffff88016c7980c0 ...

But I *really* like crash's ability to pipe and redirect commands, but that doesn't work with the x command: crash-4.0.9> x/256xg 0xffff8801aa9c8000 | grep ffff880145a194c0 crash-4.0.9> But it works with rd: crash-4.0.9> rd -x -64 0xffff8801aa9c8000 256 | grep ffff880145a194c0 ffff8801aa9c8000: ffff8800c61541c0 ffff880145a194c0 crash-4.0.9> Another fun one: crash-4.0.9> x/256xg 0xffff8801aa9c8000 | head Argument to arithmetic operation not a number or boolean. If you redirect the output of x, you get a file containing an error message: crash-4.0.9> x/256xg 0xffff8801aa9c8000 >xold.out crash-4.0.9> !sh sh-3.2$ cat xold.out No symbol "xold" in current context. sh-3.2$ The problem is that the setup of gdb commands in is_gdb_command() with merge_orig_args set puts the "| thing" or "> thing" back onto the command it is building to be passed through to gdb. I first thought that cmd_gdb() passing a NULL, instead of the fp with the redirection set up, into gdb_pass_through was part of the problem also, but that seems to be dealt with later in gdb_interface. There might some other reason for the strange behavior of merge_orig_args that my testing has not found. But otherwise, the attached patch will allow my favorite x command to be sent through pipes and redirected to files.