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?
Utilities for interactive I/O
This module is another attempt to fight the horrors of
non-blocking I/O programming. It tries to bring back the
simplicity of the declarative programming style, that is
only otherwise available when one employs threads,
coroutines, or co-processes.
Normally if a part of a pipe fails, depending on the location, it won't
be detected. This breaks down a command involving pipes and runs each
command separately.
It uses open3 to run each chunk of the pipe.
use IO::MultiPipe;
my $pipes = IO::MultiPipe->new();
#This sets the pipe that will be run.
$pipes->set('sed s/-// | sed s/123/abc/ | sed s/ABC/abc/');
if ($pipes->{error}){
print "Error!\n";
}
#'123-ABCxyz' through the command set above.
my $returned=$pipes->run('123-ABCxyz');
IO::Pager is lightweight and can be used to locate an available pager and set
$ENV{PAGER} sanely or as a factory for creating objects defined elsewhere such
as IO::Pager::Buffered and IO::Pager::Unbuffered.
IO::Pager subclasses are designed to programmatically decide whether or not to
pipe a filehandle's output to a program specified in $ENV{PAGER}. Subclasses are
only required to support filehandle output methods and close, namely
IO::Pipely - Portably create pipe() or pipe-like handles, one way or another.
Pipes are troublesome beasts because there are a few different, incompatible
ways to create them. Not all platforms support all ways, and some platforms may
have hidden difficulties like incomplete or buggy support.