in reply to Bad File Descriptor Error

... when I use File::Copy or Win32::CopyFile, I get the output file as requested along with the error.

The error variable $! is only valid immediately after an actual system error, which must be recognized by other means. If $! is nonzero that doesn't indicate an error in the preceding code. The value can come from anywhere. So you are using it wrong in your code below.

if($keepfile) { my $dest; sleep 1; eval{ $dest = $$appconfig{"destination"}."\\$filename"; Win32::CopyFile($file,$dest,1); }; if($!) { report("Error: Unable to move file to destination - ".$dest."\ +n $!"); #die; } }
Moreover, why do you run the critical statements under eval()? It will only mask some errors. If the eval() is there for a reason, you ought to inspect $@, not $! after eval finishes to detect possible errors. ($@ is unlike $! in that respect, if it's set after an eval(), there was an error.)

I believe your program is running just fine, the message in $! is irrelevant. Wy you can't copy the file using print() I don't know.

Anno

PS: The behavior of $! is as described in Unix systems. I don't know for sure about Windows.

Replies are listed 'Best First'.
Re^2: Bad File Descriptor Error
by digger (Friar) on Mar 20, 2007 at 13:18 UTC

    Thanks for taking the time to explain my misunderstanding so clearly. I am writing more apps that run in environments outside of my control, so I am trying to make the error handling more robust. My understanding of using eval in this way is that it will trap errors that may be fatal, but allow me to handle them gracefully if possible. After re-reading the perldoc for eval, I see, as you said, that I have to check $@ for error messages.

    If I am misusing eval in this context, I would appreciate any pointers.

    Thanks again
    digger

      Your eval() makes sense if Win32::CopyFile() throws exceptions at run time and you want to deal with that. I don't know if it does. The pure Perl operation
      $dest = $$appconfig{"destination"}."\\$filename";
      does not belong there. If there was a fatal error in that line, it would be a program error and you'd have to correct the line. It doesn't make sense to catch programming errors in eval().

      Anno

      These are just a couple of warnings for you (hopefully, you'll find this advice irrelevant ).

      I've run into problems with $@ on -some- Windows systems. However, you can always use $EVAL_ERROR ( $@ is shorthand for this ). I don't know where this bug comes from, sorry.

      Also, on the Emachine T2862 (and only this model, in my experience), I've had problems with:
      print HANDLE $stuff ; # doesn't seem to work on T2862

      Hopefully, you're not dealing with one of those.

      Good luck.
      Bro. Doug :wq