IO-stringy - I/O on in-core objects like strings and arrays
IO:: ::AtomicFile adpO Write a file which is updated atomically ERYQ ::Lines bdpO I/O handle to read/write to array of lines ERYQ ::Scalar RdpO I/O handle to read/write to a string ERYQ ::ScalarArray RdpO I/O handle to read/write to array of scalars ERYQ ::Wrap RdpO Wrap old-style FHs in standard OO interface ERYQ ::WrapTie adpO Tie your handles & retain full OO interface ERYQ
This toolkit primarily provides modules for performing both traditional and object-oriented i/o) on things other than normal filehandles; in particular, IO::Scalar, IO::ScalarArray, and IO::Lines.
If you have access to tie(), these classes will make use of the IO::WrapTie module to inherit a convenient new_tie() constructor. It also exports a nice wraptie() function.
In the more-traditional IO::Handle front, we have IO::AtomicFile which may be used to painlessly create files which are updated atomically.
And in the "this-may-prove-useful" corner, we have IO::Wrap, whose exported wraphandle() function will clothe anything that's not a blessed object in an IO::Handle-like wrapper... so you can just use OO syntax and stop worrying about whether your function's caller handed you a string, a globref, or a FileHandle.
Most of you already know the drill...
perl Makefile.PL
make test
make install
For everyone else out there...
if you've never installed Perl code before, or you're trying to use
this in an environment where your sysadmin or ISP won't let you do
interesting things, relax: since this module contains no binary
extensions, you can cheat. That means copying the directory tree
under my "./lib" directory into someplace where your script can "see"
it. For example, under Linux:
cp -r IO-stringy-1.234/lib/* /path/to/my/perl/
Now, in your Perl code, do this:
use lib "/path/to/my/perl";
use IO::Scalar; ### or whatever
Ok, now you've been told. At this point, anyone who whines about not being given enough information gets an unflattering haiku written about them in the next change log. I'll do it. Don't think I won't.
$Id: Stringy.pm,v 1.218 2001/02/23 07:08:00 eryq Exp $
Isn't it the case that real operating system file descriptors maintain an independent read and write file position (and seek(2) resets them both)?
He also pointed out some issues with his implementation:
For example, what does eof or tell return? The read position or
the write position? (I assumed read position was more important).
Your opinions on this are most welcome. (Me, I'm just squeamish that this will break some code which depends on the existing behavior, and that attempts to maintain backwards-compatibility will slow down the code. But I'll give it a shot.)
New "TO DO" section, because people who submit patches/ideas should at least know that they're in the system... and that I won't lose their stuff. Please read it.
New entries in AUTHOR. Please read those too.
Nasty bug fixed in IO::Scalar::write().
Apparently, the offset and the number-of-bytes arguments were,
for all practical purposes, reversed. You were okay if
you did all your writing with print(), but boy was this a stupid bug!
Thanks to Richard Jones for finding this one.
For you, Rich, a double-length haiku:
Newspaper headline
typeset by dyslexic man
loses urgency
BABY EATS FISH is
simply not equivalent
to FISH EATS BABY
New sysread and syswrite methods for IO::Scalar. Thanks again to Richard Jones for this.
Richard Jones B. K. Oxley (binkley) Doru Petrescu
Enjoy. Yell if it breaks.