in reply to Re: Moving Log files remotely
in thread Moving Log files remotely

True, true.

$! is much more important than even the filename itself. For testing and debugging purposes I usually just do a 'or die $!', that gives me the linenumber and the problem, what, most times, is all I need..
Allthough, sometimes it may be helpfull to write out the filname too, i.e. if you're not sure whether it is correct (calculated).

lg,
daniel

Replies are listed 'Best First'.
Re^3: Moving Log files remotely
by LAI (Hermit) on Sep 11, 2002 at 18:26 UTC

    Quite right. I remember when I first started writing largeish projects, and was using some OOness that got pretty convoluted at times. Often, when Perl died it spat out a filename and line number that was completely useless. It would be the file that was calling a function in another file that called a function in another file where there was a bug. I quickly learned to output readable and informative debug messages.

    Actually, AFAIR (and my memory is patchy at best) if there's a bug inside an eval statement, don't the dying words say that the problem was on line 0 or something... or just not complain at all...

    Anyway, now I have fun with error messages. Looking at debug output of my code you may see stuff like the following:

    The Command Dispatcher hates you beause: java.lang.NullPointerExceptio +n The GUI farted the following: ArrayOutOfBoundsException: 3 >= 1
    or whatever. Like I said, way too much Java lately :o)


    LAI
    :eof
Re: Re: Re: Moving Log files remotely
by helgi (Hermit) on Sep 12, 2002 at 09:46 UTC
    Hmmm. I would say both $! and the filename are very important to include in the error message, if only because malforming the filename in some way is an extremely common problem and can occur in many ways.

    What is especially insiduous and hard to track, is when a file exists with the malformed name. Now that is a real pain in the butt.

    Here are some common ways of malforming filenames:

    1 - path missing. This often occurs when using the result directly from readdir or File::Find::find without adding the path.

    2 - linebreak in filename. This typically occurs when newbies capture the output of `ls` or `dir` instead of using readdir as they should and forget to chomp.

    3 - Wrong case. Perl, like Unix, is case sensitive, but users raised on Windows and Mac systems tend to forget this.

    4 - Concatenating a file name in the wrong way, for example:

    my $path = '/usr/home/jones'; my $file = 'foo.txt'; my $filename = $path . $file.
    This will result in the nonexistent filename /usr/home/jonesfoo.txt, but is hard to catch.

    5 - Using unescaped backslashes on Windows (extremely common). Filenames like "C:\terry\new.html" are a common source of Windows/Perl nightmares (Perl reads it as "C: TAB erry NEWLINE ew.html"). Use ordinary slashes under Windows and save yourself endless hassle as well as making your code more portable as a side effect.

    I hope this helps someone.

    Regards,
    Helgi Briem