Ports 搜索

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.