in reply to Implicit closing of files

There is a difference between Perl closing a filehandle (meaning you cannot access it in your code) and Perl flushing an output buffer (meaning all the contents have been written to disk). The buffer will definitely be flushed at the end of the script. However, if you need immediate flushing, add $| =1; right after your open() call. Alternately, take a look at IO::File and the flush() method. (Due to the documentation style of the IO distribution, you actually have to look at IO::Handle for the documentation of the flush() method. But, it is available from IO::File objects.)
My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^2: Implicit closing of files
by ikegami (Patriarch) on Jun 17, 2008 at 12:57 UTC

    Are you saying the documentation is wrong? Quote close:

    Closes the file or pipe associated with the file handle, flushes the IO buffers, and closes the system file descriptor.

[reply]
      That would be correct for an explicit close(). If you let the variable fall off the end of a block, now you're depending on destruction. Destruction in Perl isn't timely.
      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

        Everything I've seen says that destruction in Perl is timely. Destruction occurs as soon as the value's ref count reaches zero. Do you have any documentation to contradict that?

        This is in contrast with Java, where garbage collection is not as predictable.

        Update: The only documentation bit I've found is in perlref:

        Hard references are smart--they keep track of reference counts for you, automatically freeing the thing referred to when its reference count goes to zero.

        And it goes on to say

        If that thing happens to be an object, the object is destructed.

        There's no mention of a delay or of it being deferred. Although it doesn't say explicitly say "immediately", I'm still convinced it is because my belief is based on much more than that one statement.

[reply]
Re^2: Implicit closing of files
by rovf (Priest) on Jun 17, 2008 at 11:39 UTC
    This means closing the filehandle is not the same as closing the file??? So, at the end of the block, only the file handle is closed and the file left being open (which of course then means that the buffers are not flushed yet)?
    I got my idea for using local file handles and their automatical closing from this article: Seven Useful Uses of local
    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
      It's not that the file is left open per se. Perl (and every other language worth using) doesn't necessarily flush buffers immediately. close() does an explicit flush and destroys the handle. However, if you let the variable fall off the end of the scope, now you're depending on destruction to close the handle (and flush the buffer). Destruction in Perl is neither ordered nor timely.
      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
        It's not that the file is left open per se. It's not that the file is left open per se. Perl ... doesn't necessarily flush buffers immediately. ... However, if you let the variable fall off the end of the scope, now you're depending on destruction to close the handle (and flush the buffer).

        I think there is a contradiction in this. Of course I/O is usually flushed, but you if I understand you right, you consider it possible that the file is not open anymore (because the handle falls out of scope), but that the buffer is flushed only if the handle is destroyed (i.e. later). But this makes no sense, IMO: You can't flush a buffer to a file, if the file is already closed.

        This leaves us with two possibilities: Either Perl does a proper close on the file, if the handle goes out of scope (which means that the buffer would be flushed), or that it does not close the file after the handle goes out of scope (and leaves it up to the destructor of the handle to flush the buffer and close the file, i.e. likely at program end).

        The first alternative would make sense. The second alternative would mean that at the end of the block, the file is still happily open.

        At least in the cases I tried, it behaved as if alternative 1 would be implemented, but I was wondering whether or not this is something I can rely to...

        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]

In Section Seekers of Perl Wisdom