Personal tools
Skip to content. | Skip to navigation
Perl has two pseudo-constants describing the current location in your source code, __FILE__ and __LINE__. This module adds __DIR__, which expands to the directory your source file is in, as an absolute pathname.
One shortcoming of the CPAN clients that currently exist is that they have no way of specifying conflicting downstream dependencies of modules. This module attempts to work around this issue by allowing you to specify conflicting versions of modules separately, and deal with them after the module is done installing. For instance, say you have a module Foo, and some other module Bar uses Foo. If Foo were to change its API in a non-backwards-compatible way, this would cause Bar to break until it is updated to use the new API. Foo can't just depend on the fixed version of Bar, because this will cause a circular dependency (because Bar is already depending on Foo), and this doesn't express intent properly anyway - Foo doesn't use Bar at all. The ideal solution would be for there to be a way to specify conflicting versions of modules in a way that would let CPAN clients update conflicting modules automatically after an existing module is upgraded, but until that happens, this module will allow users to do this manually.
The Encode module provides the interface between Perl strings and the rest of the system. Perl strings are sequences of characters.
"Errno" defines and conditionally exports all the error constants defined in your system "errno.h" include file. It has a single export tag, ":POSIX", which will export all POSIX defined error numbers.
String eval is often used for dynamic code generation. For instance, Moose uses it heavily, to generate inlined versions of accessors and constructors, which speeds code up at runtime by a significant amount. String eval is not without its issues however - it's difficult to control the scope it's used in (which determines which variables are in scope inside the eval), and it can be quite slow, especially if doing a large number of evals. This module attempts to solve both of those problems. It provides an eval_closure function, which evals a string in a clean environment, other than a fixed list of specified variables. It also caches the result of the eval, so that doing repeated evals of the same source, even with a different environment, will be much faster (but note that the description is part of the string to be evaled, so it must also be the same (or non-existent) if caching is to work properly).
This module provides Expect-like functionality to Perl. Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc.
The Exporter module implements an import method which allows a module to export functions and variables to its users' name spaces. Many modules use Exporter rather than implementing their own import method because Exporter provides a highly flexible interface, with an implementation optimized for the common case.
Exporter::Tiny supports many of Sub::Exporter's external-facing features including renaming imported functions with the -as, -prefix and -suffix options; explicit destinations with the into option; and alternative installers with the installer option. But it's written in only about 40% as many lines of code and with zero non-core dependencies. Its internal-facing interface is closer to Exporter.pm, with configuration done through the @EXPORT, @EXPORT_OK and %EXPORT_TAGS package variables. Exporter::Tiny performs most of its internal duties (including resolution of tag names to sub names, resolution of sub names to coderefs, and installation of coderefs into the target package) as method calls, which means they can be overridden to provide interesting behavior.
This module can build the C portions of Perl modules by invoking the appropriate compilers and linkers in a cross-platform manner. It was motivated by the Module::Build project, but may be useful for other purposes as well.
This Perl module is used to replace common UNIX commands. In all cases the functions work with @ARGV rather than taking arguments. This makes them easier to deal with in Makefiles.