in reply to Wierd filehandle call

Let me guess, old code? Try the following (sorry, untested) version which does the same thing in a (IMHO) clearer manner. 
use IO::Handle;

# time passes

  local *LOGFILE;
  open (LOGFILE, ">> $logFid") or die "Cannot write $logFid: $!";
  LOGFILE->autoflush();
  *STDERR = *LOGFILE;
  return (*LOGFILE, $logDate);

[download]

Replies are listed 'Best First'.
(tye)Re2: Wierd filehandle call
by tye (Sage) on Apr 04, 2001 at 22:10 UTC

    I have to discourage *STDERR= *LOGFILE. Sure, it looks nice, but it doesn't change the underlying stderr (fd 2) so that some parts of Perl (I assume) will still use the old handle as will external programs lauched by the script (or has magic to handle this been added?).

    It also leaves you in a strange situation. How do you properly close things now? To get that correct requires way too many implementation details about Perl for my taste (it may not even be possible to do it 100% correctly -- I haven't investigate the implementation details as I don't really want to know them).

    So I agree with the rest of your code but please use open to dup to STDERR instead.

    Then there is the edge case of someone using $STDERR and $LOGFILE and getting very confused. (:

            - tye (but my friends call me "Tye")
[reply]
[d/l]
      Good point about C code expecting the fd to still be 2.

      The edge case is not as bad a problem as you stated because I used local (not my because I was localizing a glob). However that does explain why the person only returned the IO part of the glob. (Of course I just store my filehandles in lexical variables.)

      And I don't understand why you think that properly closing the filehandle. I just do not issue a close anywhere, but instead store the glob in a lexical variable, and when the last reference to the open filehandle goes away, the close will happen. Or in old-style Perl you just use local on your typeglobs and again it works just fine.

      At least it works fine for as long as Perl keeps its reliable destruction semantics around...

[reply]

        As for closeing, I don't think *STDERR will ever go out of scope so I don't think anything will be closed until global destruction.

        Also, there are good reason to explicitly close (for example, to check for an error that might indicate a full file system prevented a buffer from being flushed).

                - tye (but my friends call me "Tye")
[reply]

In Section Seekers of Perl Wisdom