Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Use Perl Debugger, where input is the output from shell script

by ban (Initiate)
on Jul 23, 2013 at 18:30 UTC ( #1045931=perlquestion: print w/replies, xml ) Need Help??

ban has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to run the perl debugger on a perl script using a shell script. I am not using a terminal. I work on linux. So I created a new process and tried to add file descriptor on it. So the debugger process has a file handle 0 where it must get its input. I somehow want to feed that file 0 with the output of my shell script and stop a code if it finds a bug. Thanks to all monks...this website taught me perl :)

  • Comment on Use Perl Debugger, where input is the output from shell script

Replies are listed 'Best First'.
Re: Use Perl Debugger, where input is the output from shell script
by pemungkah (Priest) on Jul 24, 2013 at 02:26 UTC
    Feeding input to the debugger is tricky. There are three supported mechanisms: the typeahead stack, the input file handle stack, and the remote port.

    If your commands are predetermined before the debugger starts, you can use the debugger's @typeahead array to queue the lines up; the debugger's readline subroutine will read these lines preferentially over the filehandles in the filehandle stack, so you can simply add the lines you want the debugger to execute here and it will run all of them before prompting the user for further input. If you finish off with a 'q' command, it'll even exit.

    If you want to generate commands dynamically, you can use either of the other options. The input filehandle stack @DB::cmdfhs, managed by DB::readline, can be set up prior to the actual execution of the debugger so that a filehandle pointing to your program (a pipe is probably simplest here) is on the top of the stack. The debugger normally reads from the top filehandle until it reaches EOF, then pops it and moves on to the next file handle. Once we run out, it defaults to reading from the terminal. You can, instead, feed the debugger commands and then a 'q'. This is essentially what the debugger's source command does.

    You can also use the debugger's remote debugging option (which I admit I do not understand well, and which should be documented better than it is). This allows you to select a port that the debugger will listen on (essentially as the top of the filehandle stack) and interact with the debugger over that port.

    I have personally used the typeahead buffer to do setup in a debugger session (load modules, etc.) and can confirm that works fine. The readahead stack may be your simplest option if your shell script can just happily spit out commands without checking back with the debugger. If you need to actually interact with the debugger, you're going to have to use the socket option.


    • Use the readahead buffer if you can pregenerate a fixed set of commands.
    • Use the filehandle stack if you can't predetermine the commands you'll use but don't need to read any responses or output from the debugger to generate further commands.
    • Use the socket option if you really want to drive the debugger from a separate program. It may be easier to write a secondary "glue" script between your shell script and the debugger that lets the shell script think it's just reading STDIN and printing to STDOUT, but it's actually being proxied into the debugger's remote port.

    user:LanX's comments point you to the options that can be used to set up the port; I personally recommend using .perldb and either stacking the commands in @DB::typeahead or opening a pipe to your shell script and pushing that onto @DB::cmdfhs.The socket option is significantly more complicated than those two.

    If this seems a bit confusing, the only real place this is documented is in the debugger source code. Reading the debugger POD and comments may help you, especially in the case of the socket option. The code concerned with the socket option could use better comments, and if you puzzle it out better, submitting a patch to more precisely describe how it works probably wouldn't be a bad idea.

      Thanks. I was tryin to use sockets and signalhandlers to combine my script and perl debugger. thank you so much

      could you please give some resources with examples

        Take a gander at Devel::Command::Tdump for an example of using the typeahead buffer. Debug::Client seems to be a client to talk to the debugger port.

        I don't see any examples of using the filehandle stack - you probably have to do that one yourself if it turns out to be the solution you need - but the basic setup that Devel::Command::Tdump uses, of setting things up in .perldb, is probably the right point to start from; open a pipe to your client program in the BEGIN block, and push it onto @DB::cmdfhs. The debugger will read from it until it returns EOF or a 'q'commmand is seen.

Re: Use Perl Debugger, where input is the output from shell script
by LanX (Sage) on Jul 23, 2013 at 19:29 UTC
    after reading the OP again...

    have a look at PERLDB_OPTS, especially TTY and noTTY, in perldebug#Configurable Options

    Cheers Rolf

    ( addicted to the Perl Programming Language)

Re: Use Perl Debugger, where input is the output from shell script
by LanX (Sage) on Jul 23, 2013 at 18:48 UTC
    Sorry, I don't understand your question. Could you please elaborate more?

    If you wanna feed commands from a textfile into the debugger to trigger actions I'm quite sure that this is possible and documented.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1045931]
Approved by Corion
Front-paged by LanX
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2023-06-09 14:54 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (36 votes). Check out past polls.