First, you can list all of the variables and subs in use in the script by executing the following command:

perl -MO=Xref myscript.pl >myscript.xref
[download]

That will dump all kinds of good information into 'myscript.xref'.

Armed with that info, you can pick and choose which variables you want to track. From that point, have a look at my node: "Scalars tied to logfiles" to see one way of logging scalar access via Perl's tie interface. This solution would have to be adapted and reworked a bit if you wanted to also log hashes and arrays.

Another alternative is that there's probably an easier way with something in the Devel namespace.

Update: Thanks for the "lazy link alert". I was in a rush this morning when I posted it, and didn't have a chance to check. I've fixed it now.

Update2: One module to look at might be Devel::FindGlobals. It appears that if you provide it with a hash of lexical names, it will look at them too. Not sure it will give you as much info as you want or not, but it might be a start.

Lazy link alert!

Devel resolves to a user name here in PerlMonks. Perhaps you meant Search CPAN for Devel or Search perldoc.com for Devel? [Though the latter link is not very useful.]

-QM
--
Quantum Mechanics: The dreams stuff is made of

Thank you for your help I will try this after a good nights sleep

perldebug. However you may find it easier to add code in the form:

my $DEBUG = 0;   # set to > 0 for debugging, the bigger the value the 
+more verbose

# in the code wherever you think it useful
$DEBUG && DEBUG( 2, "some message" );


sub DEBUG {
    my ( $debug_level, $message ) = @_;
    # see if we want this message a current debug level
  return if $debug_level > $DEBUG;
    # we can get info on where this info comes from from caller()
    my ( $package, $file, $line ) = caller();
    # print a standard format message, say line num and message
    warn "$line\t\$message\n";
}
[download]

This is one of many ways to incorporate debugging. Just call the DEBUG function with an int first argument and a message. Set the debug level and get more verbose output. The $DEBUG && DEBUG( ... ) suntax is to avoid the sub call if we are not debugging.

I suggest you walk through the code with the debugger, setting breakpoints and gaining familiarity with the code as you go.

At least for me, working with the debugger whenever possible is the best way of finding out what is actualy happening in the program. I've often caught bugs by walking throught the code I wasn't sure of step by step, and comparing the values of the variables with what I thought they should be.

Perl debugger actualy has the functionality you're looking for (in the X command). If you're absolutely decided that you have to implement this for debugging, you can look at the debugger's code to see how it's done.

Good luck!

Thank you for your encouragement, I was begin to abandon all hope earlier today.

I would recommend the GUI based Perl debugger for doing what you're after. You can find it here. Do realize that it's only going to process one program at a time, but it will allow you to watch all the variables, how they change, and hopefully allow you to follow the program flow and what's going on.

Hope that helps!

Thanks I think this is what I could be looking for.

sub debug {
    my @vars = @_;
    my $i;
    foreach (@vars) {
       print("Var $i = $_\n");
    }
    print("\n");
    return(1);
}
[download]

My calls look like debug("Location", $arg1, $arg2, ....) for however many args you want; I just cut and paste the routine all over the place. (This is as close as I can come to a PL/1 "Put Skip Data".)

We are all Novices in the Monestary.

Were I in your position, I would build my self a little sub-routine, let us say "debug", and place calls to it at various places in the code.

Considering that 'print' with a bunch of variables was dismissed as being too much work, how is your 'debug' function going to save work? At least call it 'd', so it saves 4 keystrokes per call....

Abigail

Thanks I was here about 3 hours ago and hoped there was a system hash which stored all the user variables which I could interrogate but will go down this line now. Thank you for the encouragement.

Here's an idea that may or may not suit your needs. If you have a Windows PC, grab a Perl IDE such as OptiPerl If your Perl script runs on Windows, start the debugger and begin stepping through your code. You can inspect your variables by hovering over them with the mouse pointer, or be setting up watches. If your code runs on UNIX then you can debug remotely from your PC (see the help file).

OptiPerl is not free. I do not know if the demo version has debugging enabled, but it's ideal for novices, and reasonably inexpensive for non-commercial use.

Update: Looks like Popcorn Dave has has given you a better alternative while I was typing my reply...

And what has your question to do with its title?

Abigail

Guess your right not a lot to do with the title.

The code I have inherited makes many calls to subs, passing the whole array of arguements as referances.
What I am trying to do is have a sub somewhere which will print out all the values after the returns so that I can monitor whats being changed where.
While I could use a print statement and list all the variables, I have some 500 programs to test.

No one has mentioned Data::Dumper yet.

Is there a reason for this?

 ___
/\__\ "What is the world coming to?"
\/__/ www.wolispace.com
[download]