note ff <i> The best debugger in the universe is <code>print</code>. </i><p> <code> print STDERR "The value is [$value]\n"; </code> <p><p> To which I'd add, while not earthshaking or original, that I like using <code>warn</code> even more than <code>print STDERR</code>. Besides being shorter, the fact that it's different makes it easier to find such statements and comment out those lines when I'm through with them.<p> More particularly, I put my debugging 'warn' messages at the start of a line. Since most of my perl code has been indented a couple of tabs away from column 1, the fact that these statements are 'debug' type statements stands out. And since I might want to reuse the same debugging statements from time to time, rather than erase them when I'm done, I just comment them out when I'm "through" with them. This way, when I'm desparate later to know what's happening in some region, those previously written <code>warn</code> statements are there, waiting to be uncommented. And if I uncomment seven or eight of them (among the dozens/hundreds in my code :-), I can easily find them again to turn them off when I'm done with them by doing a vim search for them at the start of a line. <p> <code>/^warn</code><p> Then repeat my search with <code>n</code> and repeat my 'uncomment' with a dot. Because these statements are at the start of a line, they can be found differently than the <code>warn</code> statements that are in the clear and are SUPPOSED to fire when triggered by real problems.)<p> I also find that including<p> <code>use Carp qw(cluck);</code><p> early in my program and using<p> <code>cluck</code><p> statements at the start of a line (a la <code>warn</code>) helps me figure out just how a particular subroutine got invoked. 376075 376075