in reply to File I/O

Depends upon your definition of a "record". If your file contains fixed length records then is is fairly trivial to use perlfunc:seek and perlfunc:tell to position the file pointer to a specific record and overwrite the data in-place.

However, as most PC based filesystems do not have fixed-length record filetypes built-in as many mainframes do, fixed length records are fairly few and far between in the PC world. Most files therefore variable length "records", which means that you have to scan the file sequentially and remember the start position and length of each record as you go. It also means that you have to re-write every subsequent record unless your update is exactly the same length as the preceeding one.

However, the saving grace is that this has been done before, and being perl, that code is available to you on CPAN. Take a look at Tie::File. If your using a reasonably modern version of perl, this probably came with your distribution. It allows you to treat a file of fixed or variable length records as an array and takes care of all the file pointer shuffling and throws in some intelligent buffering to boot.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Replies are listed 'Best First'.
Re: Re: File I/O
by demerphq (Chancellor) on Sep 23, 2003 at 22:02 UTC

    fixed length records are fairly few and far between in the PC world.

    God I wish. :-(


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


      I meant fixed length in the mainframe sense of records addressable (directly and only) by record number.

      Fixed length records on PC's are (for the most part) only variable length bits of a stream that all happen (even by design) to be the same length. There is nothing to stop you from positioning the pointer to mid record before reading or writing, and completely corrupting the record structure in the process.

      What's the reason for you frowny? Assuming your fixed-length records are delimited with newlines, you can just as easily process them as you would variable length records with the added bonus of being able to index you way directly to a given record. Even if they are not delimited, setting $/ = \80; or whatever the fixed length is, allows you to read them just as easily.

      I don't see the problem?


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
      If I understand your problem, I can solve it! Of course, the same can be said for you.

        I have to deal with fixed length records an awful lot. Yes, they have advantages, but frankly IMO their limitations outweigh them. They scale poorly (actually, by definition, not at all) and are usually wasteful of space. And to boot are often mandated by inferior programmers who think they are making their lives easy but are in fact making them more complicated. (Hows this: fixed length records on variable length lines, with 70% wasted space. Blech.)

        Anyway, never mind me, just grumbling... :-)


        ---
        demerphq

          First they ignore you, then they laugh at you, then they fight you, then you win.
          -- Gandhi