in reply to Using +> for File Read/Write

There are two ways, with '+>' and '+<'. They are distinctly different and are used in different situations.

'+>' truncates the opened file, just like '>' does. That means the contents of the file before opening are lost. You can seek to a previous location and read/modify what you have written there. [ I've never needed to use this one, either. I'd suspect a design flaw if I did ]

'+<' is more like '<', open to read. The contents of the file are not clobbered, and the file position is set to the beginning. You can read the file and even modify it (if you preserve length or don't care about it). Having read to the end, you can freely append to it.

The commonest situation where you want to open r/w happens when the file must be flock'd to prevent races on its content. '+<' permits you to read and modify the file under a single lock.

For either, the seek, tell, and truncate builtins are often needed.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re^2: Using +> for File Read/Write
by creamygoodness (Curate) on Nov 01, 2005 at 23:54 UTC
    I've never needed to use this one, either. I'd suspect a design flaw if I did

    I've had to use it for writing certain files as part of a Lucene-compatible index. The file has to be created anew, and +< will not create a new file, only open an existing one. Later, just before the file is closed, it's necessary to seek back to near the top of the file and write a count that is not known until the rest of the file has been written.

    The file format could also have been spec'd to write the count in a tail section rather than a head, but I don't think it matters too much. Having the count at the head of the file rather than the end simplifies reading a bit. EOF really means EODATA, for instance.

    --
    Marvin Humphrey
    Rectangular Research ― http://www.rectangular.com