IO::Handle is the base class for all other IO handle classes. It is
not intended that objects of IO::Handle would be created directly,
but instead IO::Handle is inherited from by several other classes
in the IO hierarchy.
If you are reading this documentation, looking for a replacement for
the FileHandle package, then I suggest you read the documentation
for IO::File too.
Creates a IO::Handle like new does.
It requires two parameters, which are passed to the method fdopen;
if the fdopen fails, the object is destroyed. Otherwise, it is returned
to the caller.
See perlfunc for complete descriptions of each of the following
supported IO::Handle methods, which are just front ends for the
corresponding built-in functions:
See perlvar for complete descriptions of each of the following
supported IO::Handle methods. All of them return the previous
value of the attribute and takes an optional single argument that when
given will set the value. If no argument is given the previous value
is unchanged (except for $io->autoflush will actually turn ON
autoflush by default).
fdopen is like an ordinary open except that its first parameter
is not a filename but rather a file handle name, a IO::Handle object,
or a file descriptor number.
This works like <$io> described in perlop/``I/O Operators''
except that it's more readable and can be safely called in an
array context but still returns just one line.
This works like <$io> when called in an array context to
read all the remaining lines in a file, except that it's more readable.
It will also croak() if accidentally called in a scalar context.
sync synchronizes a file's in-memory state with that on the
physical medium. sync does not operate at the perlio api level, but
operates on the file descriptor, this means that any data held at the
perlio api level will not be synchronized. To synchronize data that is
buffered at the perlio api level you must use the flush method. sync
is not implemented on all platforms. See fsync(3c).
flush causes perl to flush any buffered data at the perlio api level.
Any unread data in the buffer will be discarded, and any unwritten data
will be written to the underlying file descriptor.
If called with an argument blocking will turn on non-blocking IO if
BOOL is false, and turn it off if BOOL is true.
blocking will return the value of the previous setting, or the
current setting if BOOL is not given.
If an error occurs blocking will return undef and $! will be set.
If the C functions setbuf() and/or setvbuf() are available, then
IO::Handle::setbuf and IO::Handle::setvbuf set the buffering
policy for an IO::Handle. The calling sequences for the Perl functions
are the same as their C counterparts--including the constants _IOFBF,
_IOLBF, and _IONBF for setvbuf()--except that the buffer parameter
specifies a scalar variable to use as a buffer. WARNING: A variable
used as a buffer by setbuf or setvbuf must not be modified in any
way until the IO::Handle is closed or setbuf or setvbuf is called
again, or memory corruption may result! Note that you need to import
the constants _IOFBF, _IOLBF, and _IONBF explicitly.
Lastly, there is a special method for working under -T and setuid/gid
scripts:
Marks the object as taint-clean, and as such data read from it will also
be considered taint-clean. Note that this is a very trusting action to
take, and appropriate consideration for the data source and potential
vulnerability should be kept in mind.
A IO::Handle object is a reference to a symbol/GLOB reference (see
the Symbol package). Some modules that
inherit from IO::Handle may want to keep object related variables
in the hash table part of the GLOB. In an attempt to prevent modules
trampling on each other I propose the that any such module should prefix
its variables with its own name separated by _'s. For example the IO::Socket
module keeps a timeout variable in 'io_socket_timeout'.
Due to backwards compatibility, all filehandles resemble objects
of class IO::Handle, or actually classes derived from that class.
They actually aren't. Which means you can't derive your own
class from IO::Handle and inherit those methods.