This collection of modules allows programs to be written that perform
asynchronous filehandle IO operations. A typical program using them would
consist of a single subclass of IO::Async::Set to act as a container for a
number of IO::Async::Notifier objects (or subclasses thereof). The set itself is
responsible for checking read- or write-readiness, and informing the notifiers
of these conditions. The notifiers then perform whatever work is required on
these conditions, by using subclass methods or callback functions.
IO::Callback provides an easy way to produce a phoney read-only
filehandle that calls back to your own code when it needs data to
satisfy a read. This is useful if you want to use a library module
that expects to read data from a filehandle, but you want the data to
come from some other source and you don't want to read it all into
memory and use IO::String.
The C<IO::Capture> Module defines an abstract base class that can be
used to build modules that capture output being sent on a filehandle
such as STDOUT or STDERR.
Several modules that come with the distribution, do just that.
(I.e., Capture STDOUT and STDERR) See L<IO::Capture::Overview> for a
discussion of these modules and examples of how to build a module to
sub-class from C<IO::Capture> yourself. If after reading the overview,
you would like to build a class from C<IO::Capture>, look here for
details on the internals.
It is stupidly complicated to detect whether a given scalar is a filehandle (or
something filehandle like) in Perl. This module attempts to do so, but probably
falls short in some cases. The primary advantage of using this module is that it
gives you somebody to blame (me) if your code can't detect a filehandle.
The main use case for IO::Detect is for when you are writing functions and you
want to allow the caller to pass a file as an argument without being fussy as to
whether they pass a file name or a file handle.
Inline::Files generalizes the notion of the __DATA__ marker and the
associated <DATA> filehandle, to an arbitrary number of markers and
associated filehandles.
This module allows you to calculate digests while reading or writing file
handles. This avoids the case you need to reread the same content to compute the
digests after written a file.
IO::Event provides an object-based callback system for handling nonblocking IO.
The design goal is to provide a system that just does the right thing without
the user needing to think about it much.
All APIs are kept as simple as possible yet at the same time, all functionality
is accesible if needed. Simple things are easy. Hard things are possible.
Most of the time file handling syntax will work fine: <$filehandle> and print
$filehandle 'stuff'.
IO::Event provides automatic buffering of output (with a callback to throttle).
It provides automatic line-at-a-time input.
After initial setup, call IO::Event::loop().
IO::Event was originally written to use Event. IO::Event still defaults to using
Event but it can now use AnyEvent or its own event loop.
This small low-level module only has one purpose: pass a file
descriptor to another process, using a (streaming) Unix domain socket
(on POSIX systems) or any (streaming) socket (on WIN32 systems). The
ability to pass file descriptors on windows is currently the unique
selling point of this module. Have I mentioned that it is really
small, too?
IO::File::AtomicChange - change content of a file atomically.
This module truncate and write to temporary file. When you call
$fh->close, replace target file with temporary file preserved
permission and owner (if possible).
This module provides a number of helpful routines to manipulate or
create IO::Handle like objects.