Perl Module Reference, Volume 1: Chapter 2

Perl Core Modules

This section documents the core Perl modules, many of which are included as part of the Perl distribution. This section also includes documentation of the pod modules, which describe Perl's internal document format.


Alias

  • declare symbolic aliases for Perl data

Synopsis

use Alias qw(alias const attr);
alias TEN => $ten, Ten => \$ten, Ten => \&ten,
      Ten => \@ten, Ten => \%ten, TeN => \*ten;
{
   local @Ten;
   my $ten = [1..10];
   alias Ten => $ten;   # local @Ten
}
const pi => 3.14, ten => 10;
package Foo;
use Alias;
sub new { bless {foo => 1, _bar => [2, 3]}, $_[0] }
sub a_method {
   my $s = attr shift;
   # $foo, @_bar are now local aliases for
   # $_[0]{foo}, @{$_[0]{_bar}} etc.
}
sub b_method {
  local $Alias::KeyFilter = "_";
  local $Alias::AttrPrefix = "main::";
  my $s = attr shift;
  # local @::_bar is now available, ($foo, $::foo are not)
}
sub c_method {
  local $Alias::KeyFilter = sub { $_ = shift; return (/^_/ ? 1 : 0) };
  local $Alias::AttrPrefix = sub {
                                   $_ = shift;
                                   s/^_(.+)$/main::$1/;
                                   return $_
                                 };
  my $s = attr shift;
  # local @::bar is now available, ($foo, $::foo are not)
}

Description

This module provides general mechanisms for aliasing Perl data for convenient access.

It works by putting values on the symbol table with user-supplied names. Values that are references will get dereferenced to their base types. This means that a value of [1,2,3] with a name of foo will be made available as @foo, not $foo.

The exception to this rule is the default behavior of the attr function, which will not dereference values which are blessed references (e.g., objects). See $Alias::Deref for how to change this default behavior.

Functions

alias

Given a list of name => value pairs, alias declares aliases in the caller's namespace. If the value supplied is a reference, the alias is created for the underlying value instead of the reference itself (there is no need to use this module to alias references--they are automatically "aliased" on assignment). This allows the user to alias most of the basic types.

If the value supplied is a scalar compile-time constant, the alias becomes read-only. Any attempt to write to it will fail with a run-time error.

Aliases can be dynamically scoped by predeclaring the target variable as local. Using attr for this purpose is more convenient, and recommended.

attr

Given a hash reference, attr aliases the values of the hash to the names that correspond to the keys. It always returns the supplied value. The aliases are local to the enclosing block. If any of the values are unblessed references, they are available as their dereferenced types. Thus, the action is similar to saying:

alias %{$_[0]}
but, in addition, also localizes the aliases, and does not dereference objects. Dereferencing of objects can be forced by setting the Deref option. See $Alias::Deref.

This can be used for convenient access to hash values and hash-based object attributes.

Note that this makes available the semantics of local subroutines and methods, which opens up a number of possibilities. We could make truly private methods by putting anonymous subroutines within an object. These subroutines would be available within methods where we use attr, but would not be visible to the outside world as normal methods. We could forbid recursion in methods by always putting an empty subroutine in the object hash with the same key as the method name. This would be useful where a method has to run code from other modules, but cannot be certain whether that module will call it back again.

The default behavior is to create aliases for all the entries in the hash in the caller's namespace. This can be controlled by setting a few options. See "Configuration Variables" for details.

const

This is simply a function alias for alias, described above. It is provided on demand at use time, since it reads better for constant declarations. Note that hashes and arrays cannot be constrained with const.

Configuration Variables

The following configuration variables can be used to control the behavior of the attr function. They are typically set after the use Alias; statement. Another typical usage is to localize them in a block so that their values are effective only within that block.

$Alias::KeyFilter

This constant specifies the key prefix used for determining which hash entries will be interned by attr. It can be a CODE reference, in which case it will be called with the key, and the Boolean return value determines whether that hash entry is a candidate attribute.

$Alias::AttrPrefix

This specifies a prefix to prepend to the names of localized attributes created by attr. It can be a CODE reference, in which case it will be called with the key, and the result will determine the full name of the attribute. The value can have embedded package delimiters (:: or '), which cause the attributes to be interned in that namespace instead of the caller's own namespace. For example, setting it to main:: makes use strict 'vars'; somewhat more palatable (since we can refer to the attributes as $::foo, etc., without actually declaring the attributes).

$Alias::Deref

Controls the implicit dereferencing behavior of attr. If it is set to "" or 0, attr will not dereference blessed references. If it is a true value (anything but "", 0, or a CODE reference), all references will be made available as their dereferenced types, including values that may be objects. The default is "".

This option can be used as a filter if it is set to a CODE reference, in which case it will be called with the key and the value (whenever the value happens to be a reference), and the boolean return value determines whether that particular reference must be dereferenced.

Exports

alias
attr

Examples

Run these code snippets and observe the results to become more familiar with the features of this module.

use Alias qw(alias const attr);
$ten = 10;
alias TEN => $ten, Ten => \$ten, Ten => \&ten,
      Ten => \@ten, Ten => \%ten;
alias TeN => \*ten;  # same as *TeN = *ten
# aliasing basic types
$ten = 20;
print "$TEN|$Ten|$ten\n";   # should print "20|20|20"
sub ten { print "10\n"; }
@ten = (1..10);
%ten = (a..j);
&Ten;                       # should print "10"
print @Ten, "|", %Ten, "\n";
# this will fail at run time
const _TEN_ => 10;
eval { $_TEN_ = 20 };
print $@ if $@;
# dynamically scoped aliases
@DYNAMIC = qw(m n o);
{
   my $tmp = [ qw(a b c d) ];
   local @DYNAMIC;
   alias DYNAMIC => $tmp, PERM => $tmp;
   $DYNAMIC[2] = 'zzz';
   # prints "abzzzd|abzzzd|abzzzd"
   print @$tmp, "|", @DYNAMIC, "|", @PERM, "\n";
   @DYNAMIC = qw(p q r);
   # prints "pqr|pqr|pqr"
   print @$tmp, "|", @DYNAMIC, "|", @PERM, "\n";
}
# prints "mno|pqr"
print @DYNAMIC, "|", @PERM, "\n";
# named closures
my($lex) = 'abcd';
$closure = sub { print $lex, "\n" };
alias NAMEDCLOSURE => \&$closure;
NAMEDCLOSURE();            # prints "abcd"
$lex = 'pqrs';
NAMEDCLOSURE();            # prints "pqrs"
# hash/object attributes
package Foo;
use Alias;
sub new {
  bless
    { foo => 1,
      bar => [2,3],
      buz => { a => 4},
      privmeth => sub { "private" },
      easymeth => sub { die "to recurse or to die, is the question" },
    }, $_[0];
}
sub easymeth {
  my $s = attr shift;    # localizes $foo, @bar, %buz etc with values
  eval { $s->easymeth }; # should fail
  print $@ if $@;
  # prints "1|2|3|a|4|private|"
  print join '|', $foo, @bar, %buz, $s->privmeth, "\n";
}
$foo = 6;
@bar = (7,8);
%buz = (b => 9);
Foo->new->easymeth;       # this will not recurse endlessly
# prints "6|7|8|b|9|"
print join '|', $foo, @bar, %buz, "\n";
# this should fail at run-time
eval { Foo->new->privmeth };
print $@ if $@;

Notes

It is worth repeating that the aliases created by alias and const will be created in the caller's namespace (although we can use the AttrPrefix option to specify a different namespace for attr). If that namespace happens to be localized, the aliases created will be local to that block. attr localizes the aliases for us.

Remember that references will be available as their dereferenced types.

Aliases cannot be lexical, since, by neccessity, they live on the symbol table. However, lexicals can be aliased. Note that this provides a means of reversing the action of anonymous type generators \, [] and {}. This allows us to anonymously construct data or code and give it a symbol-table presence when we choose.

Any occurrence of :: or ' in names will be treated as package qualifiers, and the value will be interned in that namespace.

Remember that aliases are very much like references, only we don't have to dereference them as often (which means we won't have to pound on the dollar signs so much). Using this module will dramatically reduce noise characters in object-oriented Perl code.

We can dynamically make subroutines and named closures with this scheme. It is also possible to alias packages, but that might be construed as abuse.

Bugs

use strict 'vars'; is not very usable, since we depend so much on the symbol table. You can declare the attributes with use vars to avoid warnings. Setting $Alias::AttrPrefix to main:: is one way to avoid use vars and frustration.

Tied variables cannot as of yet be aliased properly.

Author

Gurusamy Sarathy, gsar@umich.edu

Copyright

Copyright © 1995-97 Gurusamy Sarathy. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

See Also

perl(1)


AutoLoader

  • load functions only on demand

Synopsis

package GoodStuff;
use Exporter;
use AutoLoader;
@ISA = qw(Exporter AutoLoader);

Description

The AutoLoader module provides a standard mechanism for delayed loading of functions stored in separate files on disk. Each file has the same name as the function (plus a .al), and comes from a directory named after the package (with the auto directory). For example, the function named GoodStuff::whatever() would be loaded from the file auto/GoodStuff/whatever.al.

A module using the AutoLoader should have the special marker __END__ prior to the actual subroutine declarations. All code before this marker is loaded and compiled when the module is used. At the marker, Perl stops parsing the file.

When a subroutine not yet in memory is called, the AUTOLOAD function attempts to locate it in a directory relative to the location of the module file itself. As an example, assume POSIX.pm is located in /usr/local/lib/perl5/POSIX.pm. The AutoLoader will look for the corresponding subroutines for this package in /usr/ local/lib/perl5/auto/POSIX/*.al.

Lexicals declared with my in the main block of a package using the AutoLoader will not be visible to autoloaded functions, because the given lexical scope ends at the __END__ marker. A module using such variables as file-scoped globals will not work properly under the AutoLoader. Package globals must be used instead. When running under use strict, the use vars pragma may be employed in such situations as an alternative to explicitly qualifying all globals with the package name. Package variables predeclared with this pragma will be accessible to any autoloaded routines, but of course will not be invisible outside the module file.

The AutoLoader is a counterpart to the SelfLoader module. Both delay the loading of subroutines, but the SelfLoader accomplishes this by storing the subroutines right there in the module file rather than in separate files elsewhere. While this avoids the use of a hierarchy of disk files and the associated I/O for each routine loaded, the SelfLoader suffers a disadvantage in the one-time parsing of the lines after __DATA__, after which routines are cached. The SelfLoader can also handle multiple packages in a file.

AutoLoader, on the other hand, reads code only as it is requested, and in many cases should be faster. But it requires a mechanism like AutoSplit to create the individual files.

On systems with restrictions on filename length, the file corresponding to a subroutine may have a shorter name than the routine itself. This can lead to conflicting filenames. The AutoSplit module will warn of these potential conflicts when used to split a module.

Author

Perl5 Porters, perl5-porters@perl.org


Carp

  • generate error messages

Synopsis

use Carp;
carp "Be careful!";       # warn of errors (from perspective of caller)
croak "We're outta here!"; # die of errors (from perspective of caller)
confess "Bye!";            # die of errors with stack backtrace

Description

carp() and croak() behave like warn and die, respectively, except that they report the error as occurring not at the line of code where they are invoked, but at a line in one of the calling routines. Suppose, for example, that you have a routine goo() containing an invocation of carp(). In that caseand assuming that the current stack shows no callers from a package other than the current onecarp() will report the error as occurring where goo() was called. If, on the other hand, callers from different packages are found on the stack, then the error is reported as occurring in the package immediately preceding the package in which the carp() invocation occurs. The intent is to let library modules act a little more like built-in functions, which always report errors where you call them from.

confess() is like die except that it prints out a stack backtrace. The error is reported at the line where confess() is invoked, not at a line in one of the calling routines.

Author

Perl5 Porters, perl5-porters@perl.org


Config

  • access Perl configuration information

Synopsis

use Config;
if ($Config{cc} =~ /gcc/) {
    print "built by gcc

}

use Config qw(myconfig config_sh config_vars);
print myconfig();
print config_sh();
config_vars(qw(osname archname));

Description

The Config module contains all the information that the Configure script had to figure out at Perl build time (over 450 values).[1]

Shell variables from the config.sh file (written by Configure) are stored in a read-only hash, %Config, indexed by their names. Values set to the string undef in config.sh are returned as undefined values. The Perl exists function should be used to check whether a named variable exists.

myconfig

Returns a textual summary of the major Perl configuration values.

config_sh

Returns the entire Perl configuration information in the form of the original config.sh shell variable assignment script.

config_vars(@names)

Prints to STDOUT the values of the named configuration variables. Each is printed on a separate line in the form:

name='value';
Names that are unknown are output as name='UNKNOWN';.

Here's a more sophisticated example using %Config:

use Config;

defined $Config{sig_name} or die "No sigs?";
foreach $name (split(' ', $Config{sig_name})) {
    $signo{$name} = $i;
    $signame[$i] = $name;
    $i++;
}

print "signal #17 = $signame[17]

if ($signo{ALRM}) {
    print "SIGALRM is $signo{ALRM}
}
Because configuration information is not stored within the Perl executable itself, it is possible (but unlikely) that the information might not relate to the actual Perl binary that is being used to access it. The Config module checks the Perl version number when loaded to try to prevent gross mismatches, but can't detect subsequent rebuilds of the same version.

Author

Perl5 Porters, perl5-porters@perl.org


constant

  • Perl pragma to declare constants

Synopsis

use constant BUFFER_SIZE    => 4096;
use constant ONE_YEAR       => 365.2425 * 24 * 60 * 60;
use constant PI             => 4 * atan2 1, 1;
use constant DEBUGGING      => 0;
use constant ORACLE         => 'oracle@cs.indiana.edu';
use constant USERNAME       => scalar getpwuid($<);
use constant USERINFO       => getpwuid($<);
sub deg2rad { PI * $_[0] / 180 }
print "This line does nothing"              unless DEBUGGING;

Description

This will declare a symbol to be a constant with the given scalar or list value.

When you declare a constant such as pi using the method shown above, each machine your program runs upon can have as many digits of accuracy as it can use. Also, your program will be easier to read and more likely to be maintained, and maintained correctly (and far less likely to send a space probe to the wrong planet because nobody noticed the one equation in which you wrote 3.14195).

Notes

The value or values are evaluated in a list context. You may override this with scalar, as shown previously.

These constants do not directly interpolate into double-quoted strings, although you may use references to do so. See the perlref manpage for details about how this works.

print "The value of PI is ${\( PI )}.\n";           # scalar
print "Your USERINFO is @{[ USERINFO ]}.\n";        # list
Multiple values are returned as lists, not as arrays.

$homedir = USERINFO[7];             # WRONG
$homedir = (USERINFO)[7];           # Right
@homedir = USERINFO;                # Get the whole list
The use of all caps for constant names is merely a convention, although it is recommended in order to make constants stand out, and to help avoid collisions with other barewords, keywords, and subroutine names. Constant names must begin with a letter.

Symbols are package-scoped. That is, you can refer to a constant CONST in package Other as Other::CONST.

Omitting the value for a symbol gives it the value of undef in a scalar context or the empty list, (), in a list context. This isn't as nice as it may sound, because in this case you must either quote the symbol name or use a big arrow (=>) with nothing to point to. It is probably best to declare these explicitly.

use constant UNICORNS       => ();
use constant LOGFILE        => undef;
The result from evaluating a list constant in a scalar context is not documented, and is not guaranteed to be any particular value in the future. In particular, you should not rely upon it being the number of elements in the list, especially since it is not that value in the current implementation.

Technical Note

In the current implementation, scalar constants are actually inlinable subroutines. As of version 5.004 of Perl, the appropriate scalar constant is inserted directly in place of some subroutine calls, thereby saving the overhead of a subroutine call. See "Constant Functions" for details about how and when this happens.

Bugs

In the current version of Perl, list constants are not inlined, some symbols may be redefined without generating a warning, and defined works reliably only upon scalar constants. Also, in the current implementation, scalar constants and elements of list constants must be either undef, numbers, or strings. References are stringified, so they aren't especially useful. Magical values (such as $!) are also stringified, so they lose their magic.

It is not possible to have a subroutine or keyword with the same name as a constant. (This is probably a good thing.)

Unlike constants in some other languages, these Perl constants cannot be overridden on the command line or via environment variables.

Author

Tom Phoenix, rootbeer@teleport.com

Copyright

Copyright © 1997 Tom Phoenix

This module is free software; you can redistribute it or modify it under the same terms as Perl itself.


DynaLoader

  • automatic dynamic loading of Perl modules

Synopsis

package YourModule;
require DynaLoader;
@ISA = qw(... DynaLoader ...);

bootstrap YourModule;

Description

This module defines the standard Perl interface to the dynamic linking mechanisms available on many platforms. A common theme throughout the module system is that using a module should be easy, even if the module itself (or the installation of the module) is more complicated as a result. This applies particularly to the DynaLoader. To use it in your own module, all you need are the incantations listed above in the synopsis. This will work whether YourModule is statically or dynamically linked into Perl. (This is a Configure option for each module.) The bootstrap() method will either call YourModule's bootstrap routine directly if YourModule is statically linked into Perl, or if not, YourModule will inherit the bootstrap() method from DynaLoader, which will do everything necessary to load in your module, and then call YourModule's bootstrap() method for you, as if it were there all the time and you called it yourself. Piece of cake, of the have-it-and-eat-it-too variety.

The rest of this description talks about the DynaLoader from the viewpoint of someone who wants to extend the DynaLoader module to a new architecture. The Configure process selects which kind of dynamic loading to use by choosing to link in one of several C implementations, which must be linked into Perl statically. (This is unlike other C extensions, which provide a single implementation that may be linked in either statically or dynamically.)

The DynaLoader is designed to be a very simple, high-level interface that is sufficiently general to cover the requirements of SunOS, HP-UX, NeXT, Linux, VMS, Win-32, and other platforms. By itself, though, DynaLoader is practically useless for accessing non-Perl libraries because it provides almost no Perl-to-C "glue". There is, for example, no mechanism for calling a C library function or supplying its arguments in any sort of portable form. This job is delegated to the other extension modules that you may load in by using DynaLoader.

Internal Interface Summary

Variables:

@dl_library_path
@dl_resolve_using
@dl_require_symbols
$dl_debug
Subroutines:

bootstrap($modulename);
@filepaths = dl_findfile(@names);
$filepath = dl_expandspec($spec);
$libref  = dl_load_file($filename);
$symref  = dl_find_symbol($libref, $symbol);
@symbols = dl_undef_symbols();
dl_install_xsub($name, $symref [, $filename]);
$message = dl_error;
The bootstrap() and dl_findfile() routines are standard across all platforms, and so are defined in DynaLoader.pm. The rest of the functions are supplied by the particular .xs file that supplies the implementation for the platform. (You can examine the existing implementations in the ext/DynaLoader/*.xs files in the Perl source directory. You should also read DynaLoader.pm, of course.) These implementations may also tweak the default values of the variables listed below.

Variables

@dl_library_path

The default list of directories in which dl_findfile() will search for libraries. Directories are searched in the order they are given in this array variable, beginning with subscript 0. @dl_library_path is initialized to hold the list of "normal" directories (/usr/lib and so on) determined by the Perl installation script, Configure, and given by $Config{'libpth'}. This is to ensure portability across a wide range of platforms. @dl_library_path should also be initialized with any other directories that can be determined from the environment at run-time (such as LD_LIBRARY_PATH for SunOS). After initialization, @dl_library_path can be manipulated by an application using push and unshift before calling dl_findfile(). unshift can be used to add directories to the front of the search order either to save search time or to override standard libraries with the same name. The load function that dl_load_file() calls might require an absolute pathname. The dl_findfile() function and @dl_library_path can be used to search for and return the absolute pathname for the library/object that you wish to load.

@dl_resolve_using

A list of additional libraries or other shared objects that can be used to resolve any undefined symbols that might be generated by a later call to dl_load_file(). This is required only on some platforms that do not handle dependent libraries automatically. For example, the Socket extension shared library (auto/Socket/Socket.so) contains references to many socket functions that need to be resolved when it's loaded. Most platforms will automatically know where to find the "dependent" library (for example, /usr/lib/libsocket.so). A few platforms need to be told the location of the dependent library explicitly. Use @dl_resolve_using for this. Example:

@dl_resolve_using = dl_findfile('-lsocket');
@dl_require_symbols

A list of one or more symbol names that are in the library/object file to be dynamically loaded. This is required only on some platforms.

dl_error

Error message text from the last failed DynaLoader function.

$message = dl_error();
Note that, similar to errno in UNIX, a successful function call does not reset this message. Implementations should detect the error as soon as it occurs in any of the other functions and save the corresponding message for later retrieval. This will avoid problems on some platforms (such as SunOS) where the error message is very temporary (see, for example, dlerror(3)).

$dl_debug

Internal debugging messages are enabled when $dl_debug is set true. Currently, setting $dl_debug affects only the Perl side of the DynaLoader. These messages should help an application developer to resolve any DynaLoader usage problems. $dl_debug is set to $ENV{'PERL_DL_DEBUG'} if defined. For the DynaLoader developer and porter there is a similar debugging variable added to the C code (see dlutils.c) and enabled if Perl was built with the -DDEBUGGING flag. This can also be set via the PERL_DL_DEBUG environment variable. Set to 1 for minimal information or higher for more.

dl_findfile

Determines the full paths (including file suffix) of one or more loadable files, given their generic names and optionally one or more directories. Searches directories in @dl_library_path by default and returns an empty list if no files were found.

@filepaths = dl_findfile(@names)
Names can be specified in a variety of platform-independent forms. Any names in the form -lname are converted into libname.*, where .* is an appropriate suffix for the platform. If a name does not already have a suitable prefix or suffix, then the corresponding file will be sought by trying prefix and suffix combinations appropriate to the platform: $name.o, lib$name.* and $name. If any directories are included in @names, they are searched before @dl_library_path. Directories may be specified as -Ldir. Any other names are treated as filenames to be searched for. Using arguments of the form -Ldir and -lname is recommended. Example:

@dl_resolve_using = dl_findfile(qw(-L/usr/5lib -lposix));
dl_expandspec

Some unusual systems such as VMS require special filename handling in order to deal with symbolic names for files (that is, VMS's Logical Names). To support these systems, either a dl_expandspec() function can be implemented in the dl_*.xs file or code can be added to the autoloadable dl_expandspec() function in DynaLoader.pm.

$filepath = dl_expandspec($spec)
dl_load_file

Dynamically load $filename, which must be the path to a shared object or library. An opaque "library reference" is returned as a handle for the loaded object.

$libref = dl_load_file($filename)
dl_load_file() returns the undefined value on error. (On systems that provide a handle for the loaded object such as SunOS and HP-UX, the returned handle will be $libref. On other systems $libref will typically be $filename or a pointer to a buffer containing $filename. The application should not examine or alter $libref in any way.) Below are some of the functions that do the real work. Such functions should use the current values of @dl_require_symbols and @dl_resolve_using if required.

SunOS:  dlopen($filename)
HP-UX:  shl_load($filename)
Linux:  dld_create_reference(@dl_require_symbols);
        dld_link($filename)
NeXT:   rld_load($filename, @dl_resolve_using)
VMS:    lib$find_image_symbol($filename,
                              $dl_require_symbols[0])
dl_find_symbol

Returns the address of the symbol $symbol, or the undefined value if not found.

$symref = dl_find_symbol($libref, $symbol)
If the target system has separate functions to search for symbols of different types, then dl_find_symbol() should search for function symbols first and then search for other types. The exact manner in which the address is returned in $symref is not currently defined. The only initial requirement is that $symref can be passed to, and understood by, dl_install_xsub(). Here are some current implementations:

SunOS:  dlsym($libref, $symbol)
HP-UX:  shl_findsym($libref, $symbol)
Linux:  dld_get_func($symbol) and/or dld_get_symbol($symbol)
NeXT:   rld_lookup("_$symbol")
VMS:    lib$find_image_symbol($libref, $symbol)
dl_undef_symbols

Returns a list of symbol names which remain undefined after dl_load_file().

@symbols = dl_undef_symbols()
It returns () if these names are not known. Don't worry if your platform does not provide a mechanism for this. Most platforms do not need it and hence do not provide it; they just return an empty list.

dl_install_xsub

Creates a new Perl external subroutine named $perl_name using $symref as a pointer to the function that implements the routine.

dl_install_xsub($perl_name, $symref [, $filename])
This is simply a direct call to newXSUB(). It returns a reference to the installed function. The $filename parameter is used by Perl to identify the source file for the function if required by die, caller, or the debugger. If $filename is not defined, then DynaLoader will be used.

bootstrap()

This is the normal entry point for automatic dynamic loading in Perl.

bootstrap($module);
It performs the following actions:

Author

Perl5 Porters, perl5-porters@perl.org


English

  • use English or awk names for punctuation variables

Synopsis

use English;
...
if ($ERRNO =~ /denied/) { ... }

Description

This module provides aliases for the built-in "punctuation" variables. Variables with side effects that get triggered merely by accessing them (like $0) will still have the same effects under the aliases.

For those variables that have an awk(1) version, both long and short English alternatives are provided. For example, the $/ variable can be referred to either as $RS or as $INPUT_RECORD_SEPARATOR if you are using the English module.

Here is the list of variables along with their English alternatives:

PerlEnglish PerlEnglish
@_@ARG $?$CHILD_ERROR
$_$ARG $!$OS_ERROR
$&$MATCH $!$ERRNO
$`$PREMATCH $@$EVAL_ERROR
$'$POSTMATCH $$$PROCESS_ID
$+$LAST_PAREN_MATCH $$$PID
$.$INPUT_LINE_NUMBER $<$REAL_USER_ID
$.$NR $<$UID
$/$INPUT_RECORD_SEPARATOR $>$EFFECTIVE_USER_ID
$/$RS $>$EUID
$|$OUTPUT_AUTOFLUSH $($REAL_GROUP_ID
$,$OUTPUT_FIELD_SEPARATOR $($GID
$,$OFS $)$EFFECTIVE_GROUP_ID

Author

Perl5 Porters, perl5-porters@perl.org


Exporter

  • default import method for modules

Synopsis

# in module YourModule.pm:
package YourModule;
use Exporter ();
@ISA = qw(Exporter);

@EXPORT = qw(...);              # Symbols to export by default.
@EXPORT_OK = qw(...);           # Symbols to export on request.
%EXPORT_TAGS = (tag => [...]);  # Define names for sets of symbols.

# in other files that wish to use YourModule:
use YourModule;              # Import default symbols into my package.
use YourModule qw(...);      # Import listed symbols into my package.
use YourModule ();           # Do not import any symbols!

Description

Any module may define a class method called import(). Perl automatically calls a module's import() method when processing the use statement for the module. The module itself doesn't have to define the import() method, though. The Exporter module implements a default import() method that many modules choose to inherit instead. The Exporter module supplies the customary import semantics, and any other import() methods will tend to deviate from the normal import semantics in various (hopefully documented) ways. Now we'll talk about the normal import semantics.

Specialized Import Lists

Ignoring the class name, which is always the first argument to a class method, the arguments that are passed into the import() method are known as an import list. Usually the import list is nothing more than a list of subroutine or variable names, but occasionally you may want to get fancy. If the first entry in an import list begins with !, :, or /, the list is treated as a series of specifications that either add to or delete from the list of names to import. They are processed left to right. Specifications are in the form:

SymbolMeaning
[!]nameThis name only
[!]:DEFAULTAll names in @EXPORT
[!]:tagAll names in $EXPORT_TAGS (tag) anonymous list
[!]/pattern/All names in @EXPORT and @EXPORT_OK that match pattern

A leading ! indicates that matching names should be deleted from the list of names to import. If the first specification is a deletion, it is treated as though preceded by :DEFAULT. If you just want to import extra names in addition to the default set, you will still need to include :DEFAULT explicitly.

For example, suppose that YourModule.pm says:

@EXPORT      = qw(A1 A2 A3 A4 A5);
@EXPORT_OK   = qw(B1 B2 B3 B4 B5);
%EXPORT_TAGS = (
    T1 => [qw(A1 A2 B1 B2)],
    T2 => [qw(A1 A2 B3 B4)]
);
Individual names in EXPORT_TAGS must also appear in @EXPORT or @EXPORT_OK. Note that you cannot use the tags directly within either @EXPORT or @EXPORT_OK (though you could preprocess tags into either of those arrays, and in fact, the export_tags() and export_ok_tags() functions below do precisely that).

An application using YourModule can then say something like this:

use YourModule qw(:DEFAULT :T2 !B3 A3);
The :DEFAULT adds in A1, A2, A3, A4, and A5. The :T2 adds in only B3 and B4, since A1 and A2 were already added. The !B3 then deletes B3, and the A3 does nothing because A3 was already included. Other examples include:

use Socket qw(!/^[AP]F_/ !SOMAXCONN !SOL_SOCKET);
use POSIX  qw(:errno_h :termios_h !TCSADRAIN !/^EXIT/);
Remember that most patterns (using //) will need to be anchored with a leading ^, for example, /^EXIT/ rather than /EXIT/.

You can say:

BEGIN { $Exporter::Verbose=1 }
in order to see how the specifications are being processed and what is actually being imported into modules.

Module Version Checking

The Exporter module will convert an attempt to import a number from a module into a call to $module_name->require_version($value). This can be used to validate that the version of the module being used is greater than or equal to the required version. The Exporter module also supplies a default require_version() method, which checks the value of $VERSION in the exporting module.

Since the default require_version() method treats the $VERSION number as a simple numeric value, it will regard version 1.10 as lower than 1.9. For this reason it is strongly recommended that the module developer use numbers with at least two decimal places; for example, 1.09.

Prior to release 5.004 or so of Perl, this worked only with modules that use the Exporter module; in particular, this means that you can't check the version of a class module that doesn't require the Exporter module.

Managing Unknown Symbols

In some situations you may want to prevent certain symbols from being exported. Typically this applies to extensions with functions or constants that may not exist on some systems.

The names of any symbols that cannot be exported should be listed in the @EXPORT_FAIL array.

If a module attempts to import any of these symbols, the Exporter will give the module an opportunity to handle the situation before generating an error. The Exporter will call an export_fail() method with a list of the failed symbols:

@failed_symbols = $module_name->export_fail(@failed_symbols);
If the export_fail() method returns an empty list, then no error is recorded and all requested symbols are exported. If the returned list is not empty, then an error is generated for each symbol and the export fails. The Exporter provides a default export_fail() method that simply returns the list unchanged.

Uses for the export_fail() method include giving better error messages for some symbols and performing lazy architectural checks. Put more symbols into @EXPORT_FAIL by default and then take them out if someone actually tries to use them and an expensive check shows that they are usable on that platform.

Tag Handling Utility Functions

Since the symbols listed within %EXPORT_TAGS must also appear in either @EXPORT or @EXPORT_OK, two utility functions are provided that allow you to easily add tagged sets of symbols to @EXPORT or @EXPORT_OK:

%EXPORT_TAGS = (Bactrian => [qw(aa bb cc)],
                Dromedary => [qw(aa cc dd)]);
Exporter::export_tags('Bactrian');   # add aa bb cc to @EXPORT
Exporter::export_ok_tags('Dromedary'); # add aa cc dd to @EXPORT_OK
Any names that are not tags are added to @EXPORT or @EXPORT_OK unchanged, but will trigger a warning (with Ðw) to avoid misspelled tag names being silently added to @EXPORT or @EXPORT_OK. Future versions may regard this as a fatal error.

Author

Perl5 Porters, perl5-porters@perl.org


Filter::cpp

  • cpp source filter

Synopsis

use Filter::cpp;

Description

This source filter pipes the current source file through the C preprocessor (cpp) if it is available.

As with all source filters, its scope is limited to the current source file only. Every file you want to be processed by the filter must have the line:

use Filter::cpp ;
near the top.

Here is an example script that uses the filter:

use Filter::cpp ;
#define FRED 1
$a = 2 + FRED ;
print "a = $a\n" ;
#ifdef FRED
print "Hello FRED\n" ;
#else
print "Where is FRED\n" ;
#endif
This is what it will output:

a = 3
Hello FRED

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::decrypt

  • template for a decrypt source filter

Synopsis

use Filter::decrypt;

Description

This is a sample decrypting source filter.

Although this is a fully functional source filter, which does implement a very simple decrypt algorithm, it is not intended to be used as it is supplied. Consider it as a template which you can combine with a proper decryption algorithm to develop your own decryption filter.

Warning

It is important to note that a decryption filter can never provide complete security against attack. At some point the parser within Perl needs to be able to scan the original decrypted source. This means that at some stage, fragments of the source will exist in a memory buffer.

The best you can hope to achieve by decrypting your Perl source using a source filter is to make it impractical to crack.

Given that proviso, there are a number of things you can do to make life more difficult for the prospective cracker.

  • Strip the Perl binary to remove all symbols.

  • Build the decrypt extension using static linking. If the extension is provided as a dynamic module, there is nothing to stop someone from linking it at run time with a modified Perl binary.

  • Do not build Perl with -DDEBUGGING. If you do, your source can be retrieved with the -Dp command-line option. (The sample filter contains logic to detect the DEBUGGING option.)

  • Do not build Perl with C debugging support enabled.

  • Do not implement the decryption filter as a subprocess (like the cpp source filter). It is possible to peek into the pipe that connects to the subprocess.

  • Do not use the decrypt filter as-is. The algorithm used in this filter has been purposefully left simple.

If you feel that the source filtering mechanism is still not secure enough, you could try using the unexec/undump method. See the Perl FAQ for further details.

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::exec

  • exec source filter

Synopsis

use Filter::exec qw(command parameters) ;

Description

This filter pipes the current source file through the program that corresponds to the given command (with possible parameters).

As with all source filters, its scope is limited to the current source file only. Every file you want to be processed by the filter must have the line:

use Filter::exec qw(command) ;
near the top.

Here is an example script which uses the filter:

use Filter::exec qw(tr XYZ PQR) ;
$a = 1 ;
print "XYZ a = $a\n" ;
This is the output:

PQR = 1

Warning

You should be very careful when using this filter. Because of the way the filter is implemented it is possible to end up with deadlock. Be especially careful when stacking multiple instances of the filter in a single source file.

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::sh

  • sh source filter

Synopsis

use Filter::sh 'command' ;

Description

This filter pipes the current source file through the program that corresponds to the command parameter using the Bourne shell.

As with all source filters, its scope is limited to the current source file only. Every file you want to be processed by the filter must have this line near the top:

use Filter::sh 'command' ;
Here is an example script that uses the filter:

use Filter::sh 'tr XYZ PQR' ;
$a = 1 ;
print "XYZ a = $a\n" ;
This is what it will output:

PQR = 1

Warning

You should be very careful when using this filter. Because of the way the filter is implemented it is possible to end up with deadlock. Be especially careful when stacking multiple instances of the filter in a single source file.

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::tee

  • tee source filter

Synopsis

use Filter::tee 'filename' ;
use Filter::tee '>filename' ;
use Filter::tee '>>filename' ;

Description

This filter copies all text from the line after the use in the current source file to the file specified by the parameter filename.

By default (and when the filename is prefixed with a >), the output file will be emptied first if it already exists.

If the output filename is prefixed with >>, it will be opened for appending.

This filter is useful as a debugging aid when developing other source filters.

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::Util::Call

  • Perl Source Filter Utility Module

Synopsis

Method filter:

package MyFilter ;

use Filter::Util::Call ;
sub import
{
    my($type, @arguments) = @_ ;
    filter_add([]) ;
}

sub filter
{
    my($self) = @_ ;
    my($status) ;

    $status = filter_read() ;
    $status ;
}

1 ;
Closure filter:

package MyFilter ;

use Filter::Util::Call ;
sub import
{
    my($type, @arguments) = @_ ;

    filter_add(
        sub
        {
            my($status) ;
            $status = filter_read() ;
            $status ;
        } )
}

1 ;

Description

This module provides you with the framework to write source filters in Perl.

A Perl source filter is implemented as a Perl module. The structure of the module can take one of two broadly similar formats (as shown previously in the Synopsis). To distinguish between them, the first will be referred to as a method filter and the second as a closure filter.

To make use of either of the two filter modules, place the line shown here in a Perl source file:

use MyFilter;
The skeleton modules shown above are fully functional source filters, albeit fairly useless ones. As they stand, all they do is pass the source stream through, without modifying it at all.

As you can see, both modules have a broadly similar structure. They both make use of the Filter::Util::Call module and both have an import method. The difference between them is that the method filter requires a filter method, whereas the closure filter gets the equivalent of a filter method with the anonymous subroutine passed to filter_add.

To make proper use of the closure filter shown above you need to have a good understanding of the concept of a closure. See the perlref manpage for more details on the mechanics of closures.

Methods

The following methods are included in Filter::Util::Call:

import()

The import method is used to create an instance of the filter. It is called indirectly by Perl when it encounters the use MyFilter line in a source file (See import for more details on import).

It will always have at least one parameter automatically passed by Perl corresponding to the name of the package. In the example above it will be MyFilter.

Apart from the first parameter, import can accept an optional list of parameters. These can be used to pass parameters to the filter. For example:

use MyFilter qw(a b c);
will result in the @_ array having the following values:

@_ [0] => "MyFilter"
@_ [1] => "a"
@_ [2] => "b"
@_ [3] => "c"
Before terminating, the import function must explicitly install the filter by calling filter_add.

filter() (or anonymous sub)

Either the filter method (used with a method filter) or the anonymous sub (used with a closure filter) is where the main processing for the filter is done.

The difference between the two types of filters is that the method filter uses the object passed to the method to store any context data, whereas the closure filter uses the lexical variables that are maintained by the closure.

Note that the single parameter passed to the method filter, $self, is the same reference that was passed to filter_add and blessed into the filter's package. See the example filters later on for details of using $self.

Here is a list of the common features of the anonymous sub and the filter() method.

$_

Although $_ doesn't actually appear explicitly in the sample filters shown earlier, it is implicitly used in a number of places.

First, when either filter or the anonymous sub are called, a local copy of $_ will automatically be created. It will always contain the empty string at this point.

Next, both filter_read and filter_read_exact will append any source data that is read to the end of $_.

Finally, when filter or the anonymous sub are finished processing, they are expected to return the filtered source using $_.

This implicit use of $_ greatly simplifies the filter.

$status

The status value, which is returned by the user's filter method or anonymous sub, and the filter_read and filter_read_exact functions take the same set of values, namely:

< 0  Error
= 0  EOF
> 0  OK
filter_read, filter_read_exact, and filter_del

These functions are common to both types of filters. See the description under "Functions."

Functions

Filter::Util::Call provides the following functions:

filter_add()

The function, filter_add, actually installs the filter. It takes one parameter, which should be a reference. The kind of reference used will dictate which of the two filter types will be used.

If a CODE reference is used, a closure filter will be assumed.

If a CODE reference is not used, a method filter will be assumed. In a method filter, the reference can be used to store context information. The reference will be blessed into the package by filter_add.

See the filters at the end of this document for examples of using context information using both method filters and closure filters.

filter_read() and filter_read_exact()

These functions are used by the filter to obtain either a line or block from the next filter in the chain, or the actual source file if there aren't any other filters.

The function filter_read takes two forms:

$status = filter_read() ;
$status = filter_read($size) ;
The first form is used to request a line, while the second requests a block.

In line mode, filter_read will append the next source line to the end of the $_ scalar.

In block mode, filter_read will append a block of data that is <= $size to the end of the $_ scalar. It is important to emphasise the that filter_read will not necessarily read a block of precisely $size bytes.

If you need to be able to read a block that has an exact size, you can use the function filter_read_exact. It works identically to filter_read in block mode, except it will try to read a block of exactly $size bytes in length. The only circumstances in which it will not return a block of $size bytes long is on EOF or error.

It is very important to check the value of $status after every call to filter_read or filter_read_exact.

filter_del()

The function filter_del is used to disable the current filter. It does not affect the running of the filter. All it does is tell Perl not to call the filter anymore.

See "Example 4: Using filter_del" for details.

Exports

The following functions are exported by Filter::Util::Call:

filter_add()
filter_read()
filter_read_exact()
filter_del()

Examples

Here are a few examples which simply illustrate the key concepts, as most of them (in their current form) are of little practical use.

The examples subdirectory has copies of all these filters implemented both as method filters and as closure filters.

Example 1: A simple filter

Below is a method filter which is hard-wired to replace all occurrences of the string Joe with Jim.

package Joe2Jim ;

use Filter::Util::Call ;
sub import
{
    my($type) = @_ ;

    filter_add(bless []) ;
}

sub filter
{
    my($self) = @_ ;
    my($status) ;

    s/Joe/Jim/g
        if ($status = filter_read()) > 0 ;
    $status ;
}

1 ;
Here is an example of using the filter:

use Joe2Jim ;
print "Where is Joe?\n" ;
This is what the script above will print:

Where is Jim?

Example 2: Using the context

To make the previous example more usuable in real-world scenarios, we make use of the context data and allow arbitrary from and to strings to be used. This time we will use a closure filter. To reflect its enhanced role, the filter is called Subst:

package Subst ;

use Filter::Util::Call ;
use Carp ;

sub import
{
    croak("usage: use Subst qw(from to)")
        unless @_ == 3 ;
    my ($self, $from, $to) = @_ ;
    filter_add(
        sub
        {
            my ($status) ;
            s/$from/$to/
                if ($status = filter_read()) > 0 ;
            $status ;
        })
}
1 ;
and is used like this:

use Subst qw(Joe Jim) ;
print "Where is Joe?\n" ;

Example 3: Using the context within the filter

Here is a filter that is a variation of the Joe2Jim filter. As well as substituting all occurrences of Joe to Jim, it keeps a count of the number of substitutions made in the context object.

Once EOF is detected ($status is zero) the filter will insert an extra line into the source stream. When this extra line is executed it will print a count of the number of substitutions actually made. Note that $status is set to 1 in this case.

package Count ;

use Filter::Util::Call ;

sub filter
{
    my ($self) = @_ ;
    my ($status) ;

    if (($status = filter_read()) > 0 ) {
        s/Joe/Jim/g ;
        ++ $$self ;
    }
    elsif ($$self >= 0) { # EOF
        $_ = "print q[Made ${$self} substitutions\n]" ;
        $status = 1 ;
        $$self = -1 ;
    }
    $status ;
}

sub import
{
    my ($self) = @_ ;
    my ($count) = 0 ;
    filter_add(\$count) ;
}

1 ;
Here is a script which uses this filter:

use Count ;
print "Hello Joe\n" ;
print "Where is Joe\n" ;
It outputs:

Hello Jim
Where is Jim
Made 2 substitutions

Example 4: Using filter_del

Another variation on a theme, this filter modifies the Subst filter to allow a starting and stopping pattern to be specified as well as the from and to patterns. If you know the vi editor, it is equivalent to this command:

:/start/,/stop/s/from/to/
When used as a filter we want to invoke it like this:

use NewSubst qw(start stop from to) ;
Here is the module:

package NewSubst ;

use Filter::Util::Call ;
use Carp ;

sub import
{
    my ($self, $start, $stop, $from, $to) = @_ ;
    my ($found) = 0 ;
    croak("usage: use Subst qw(start stop from to)")
        unless @_ == 5 ;

    filter_add(
        sub
        {
            my ($status) ;

            if (($status = filter_read()) > 0) {

                $found = 1
                    if $found == 0 and /$start/ ;

                if ($found) {
                    s/$from/$to/ ;
                    filter_del() if /$stop/ ;
                }

            }
            $status ;
        } )

}

1 ;

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


Filter::Util::Exec

  • exec source filter

Description

This module is provides the interface to allow the creation of source filters that use a UNIX coprocess.

See Filter::exec, Filter::cpp and Filter::sh for examples of the use of this module.

Author

Paul Marquess, pmarquess@bfsec.bt.co.uk


perlpod

  • plain old documentation

Description

A pod-to-whatever translator reads a pod file paragraph by paragraph and translates it to the appropriate output format. There are three kinds of paragraphs:

  • A verbatim paragraph, distinguished by being indented (that is, it starts with space or tab). It should be reproduced exactly, with tabs assumed to be on eight-column boundaries. There are no special formatting escapes, so you can't italicize or anything like that. A \ means \, and nothing else.

  • A command. All command paragraphs start with =, followed by an identifier, followed by arbitrary text that the command can use however it pleases. Currently recognized commands are:

=head1 heading
=head2 heading
=item text
=over N
=back
=cut
=pod
=for X
=begin X
=end X
The =pod directive does nothing beyond telling the compiler to lay off parsing code through the next =cut. It's useful for adding another paragraph to the doc if you're mixing up code and pod a lot.

head1 and head2 produce first- and second-level headings, with the text in the same paragraph as the =headn directive forming the heading description.

item, over, and back require a little more explanation: =over starts a section specifically for the generation of a list using =item commands. At the end of your list, use =back to end it. You will probably want to use 4 as the number to =over (i.e., =over 4), as some formatters use this for indentation. This should probably be a default. Note also that there are some basic rules to using =item:

    • Don't use it outside an =over/=back block

    • Use at least one inside an =over/=back block

    • You don't have to include the =back if the list just runs off the document

    • Perhaps most important, keep the items consistent: either use =item * for all of them, to produce bullets, or use =item 1., =item 2., etc., to produce numbered lists, or use =item foo, =item bar, etc., (i.e., things that look nothing like bullets or numbers). If you start with bullets or numbers, stick with them, as many formatters use the first =item type to decide how to format the list.

      for, begin, and end let you include sections that are not interpreted as pod text, but are passed directly to particular formatters. A formatter that can utilize that format will use the section, otherwise it will completely ignore it. The directive =for specifies that the entire next paragraph is in the format indicated by the first word after =for, like this:

=for html <br>
<p> This is a raw HTML paragraph </p>
The paired commands =begin and =end work very similarly to =for, but instead of only accepting a single paragraph, all text from =begin to a paragraph with a matching =end are treated as a particular format.

Here are some examples of how to use these:

=begin html

<br>Figure 1.<IMG SRC="figure1.png"><br>

=end html

=begin text

  ---------------
  |  foo        |
  |        bar  |
  ---------------

^^^^ Figure 1. ^^^^

=end text
Some format names that formatters currently are known to accept include roff, man, latex, tex, text, and html. (Some formatters treat some of these as synonyms.)

And don't forget, when using any command, that the command lasts until the end of the paragraph, not the line. Hence in the examples below, you can see the empty line after each command to end its paragraph.

Some examples of lists include:

=over 4

=item *

First item

=item *

Second item

=back

=over 4

=item Foo()

Description of Foo function

=item Bar()

Description of Bar function

=back
  • An ordinary block of text. It is filled, and maybe even justified. Certain interior sequences are recognized, both here and in commands:

I<text>     Italicize text, used for emphasis or variables
B<text>     Embolden text, used for switches and programs
S<text>     Text contains non-breaking spaces
C<code>     Literal code
L<name>     A link (cross-reference) to name
            L<name>            Manual page
            L<name/ident>      Item in manual page
            L<name/"sec">      Section in other manual page
            L<"sec">           Section in this manual page
                               (the quotes are optional)
            L</"sec">          Ditto
F<file>     A filename
X<index>    An index entry
Z<>         A zero-width character
E<escape>   A named character (very similar to HTML escapes)
            E<lt>              A literal <
            E<gt>              A literal >
            (These are optional, except in other interior
            sequences and when preceded by a capital letter)
            E<n>               Character number n (probably ASCII)
            E<html>            Some non-numeric HTML entity, such
                               as E<Agrave>
That's it. The intent is simplicity, not power. I wanted paragraphs to look like paragraphs (block format), so that they stand out visually, and so that I could run them through fmt easily to reformat them (that's F7 in my version of vi). I wanted the translator (and not me) to worry about whether " or ' is a left quote or a right quote within filled text, and I wanted it to leave the quotes alone, dammit, in verbatim mode, so I could slurp in a working program, shift it over four spaces, and have it print out, er, verbatim. And presumably in a constant-width font.

In particular, you can leave things like this verbatim in your text:

    • Perl

    • FILEHANDLE

    • $variable

    • function()

    • manpage(3r)

      Doubtless a few other commands or sequences will need to be added along the way, but I've gotten along surprisingly well with just these.

      Note that I'm not at all claiming this to be sufficient for producing a book. I'm just trying to make an idiot-proof common source for nroff, TeX, and other markup languages, as used for online documentation. Translators exist for pod2man (that's for nroff(1) and troff(1)), pod2html, pod2latex, and pod2fm.

Embedding Pods in Perl Modules

You can embed pod documentation in your Perl scripts. Start your documentation with =head1 at the beginning and end it with =cut. Perl ignores the pod text. See any of the supplied library modules for examples. If you're going to put your pods at the end of the file, and you're using an __END__ or __DATA__ cut mark, make sure to put an empty line there before the first pod directive.

__END__

=head1 NAME

modern - I am a modern module
If you had not had that empty line there, then the translators wouldn't have seen the pod.

Common Pod Pitfalls

    • Pod translators usually require paragraphs to be separated by completely empty lines. If you have an apparently empty line with some spaces on it, this can cause odd formatting.

    • Translators mostly add wording around an L<> link, so that L<foo(1)> becomes "the foo(1) manpage", for example (see pod2man for details). Thus, you shouldn't write things like "the L<foo> manpage", if you want the translated document to read sensibly.

    • The script pod/checkpods.PL in the Perl source distribution provides skeletal checking for lines that look empty but aren't, but it is there only as a placeholder until someone writes Pod::Checker. The best way to check your pod is to pass it through one or more translators and proofread the result, or print out the result and proofread that. Some of the problems found may be bugs in the translators, which you may or may not wish to work around.

Author

Larry Wall

See Also

pod2man, PODs: Embedded Documentation


Pod::Text

  • a class for converting pod data to formatted ASCII text

Synopsis

use Pod::Text;
pod2text("perlfunc.pod");
or:

use Pod::Text;
package MyParser;
@ISA = qw(Pod::Text);
sub new {
   ## constructor code ...
}
## implementation of appropriate subclass methods ...
package main;
$parser = new MyParser;
@ARGV = ('-')  unless (@ARGV > 0);
for (@ARGV) {
   $parser->parse_from_file($_);
}

Description

Pod::Text is a module that can convert documentation in the pod format (such as can be found throughout the Perl distribution) into formatted ASCII. Termcap is optionally supported for boldface/underline and can be enabled via $Pod::Text::termcap=1. If termcap has not been enabled, then backspaces are used to simulate bold and underlined text.

A separate pod2text program is included, which is primarily a wrapper for Pod::Text::pod2text().

The single function pod2text() can take one or two arguments. The first should be the name of a file to read the pod from, or <&STDIN to read from STDIN. The second argument, if provided, should be a filehandle glob where output should be sent.

Author

Tom Christiansen, tchrist@mox.perl.com

Modified to derive from Pod::Parser by Brad Appleton, Brad_Appleton-GBDA001@email.mot.com

See Also

Pod::Parser


pod2fm

  • convert pod format to FrameMaker documents and book file

Synopsis

pod2fm [-mmlonly |
        -nodoc [-lock]
        [-book [book_name] [-noopen]
            [-template document [-format types]... [-toc] [-index]
       ]
   ]

Description

This program parses all files a with .pod extension and creates FrameMaker documents. You can control what is generated by arguments given on the command line. pod2fm can:

  • Generate Frame MML, MIF, and binary formats

  • Generate hypertext links to a group of documents

  • Create a Frame "book" that includes all of the documents from a run

  • Create Table of Contents and Index documents

  • Create documents that can be used with FrameViewer for online docs

Options

-mmlonly
-nommlonly
This switch tells pod2fm if it should stop execution after it has generated the MML version of the document. The document is written into a file with the .mml extension.
If -mmlonly is specified, it has to be the only command-line switch.
The default is -nommlonly.

-nodoc
-doc
The switch instructs pod2fm to use the FrameMaker tool fmbatch to convert the .doc file, which is in MIF format, to the binary FrameMaker format.
The default is -doc.

-lock
-nolock
Pod2fm generates hypertext markers so that if you to click on a marked word in a document, Frame will take you to the spot in a document that the marker is pointing to. To be able to use this feature, you need to save the documents as locked or read-only. The -lock option causes pod2fm to generate locked versions of the documents.
The -lock option only works if you are generating binary documents. (See the doc option.)
The default is -nolock.

-book [book_name]
This switch allows pod2fm to create a FrameMaker book file that contains all the documents that are on the command line. A book is a way to organize a group of related documents so they can be operated on at the same time. A book file allows you to apply a common format to all the documents and to print them at the same time.
book_name is an optional argument to -book. It allows you to specify a name for the book file. If book_name is not specified, it defaults to perl. In any case, the filename extension is .book.

-noopen
-open
If this option is on the command line, pod2fm tries to open the book it created in FrameMaker. Because this options works on the book file, you must be generating a book with the -book option.
The default is -open.

-template document
Pod2fm generates a minimal format for the documents it produces. You can use the -template option to specify a template document that pod2fm can copy the format from so that you can control the format. You can control which format in the template document to use with the -format option. The document name is a required argument to -template and specifies the path to the document template.

-format type
The option -format allows you to control which format to copy from the template document specified with the -template option. You can specify one or more arguments to each -format option by providing a comma-separated list of format types, like this:

-format Page,Paragraph,Character
You can also have more than one -format option on the command line.
The legal format types are:
all
All types are specified (the default)

Character
Character formats

Paragraph
Paragraph formats

Page
Master page layouts

Reference
Reference page layouts

Table
Table formats

Variables
Variable definitions

Math
Math definitions

Cross
Cross-reference definitions

Color
Color definitions

Conditional
Conditional text definitions

There are two additional types that can be included as an argument to control how the other types are used:

Break
Preserve page breaks

Other
Preserve other format changes

-toc
-notoc
-index
-noindex
When you are generating a book from a template with pod2fm, you can generate a Table of Contents and an Index by specifying the -toc and the -index options. See the "Table of Contents" and "Index" subsections of the "TEMPLATES" section of this manpage, for more information.
The defaults are -notoc and -noindex.

Templates

By using the -template command-line option when you are generating a book using the -book option, you can override the default formats that pod2fm produces.

A template is a FrameMaker document, in binary form or MIF, that has formats you want already applied to it. With this version of pod2fm, you can override the Master Page and Reference Page layouts, and paragraph formats. There are other formats that you can specify, like character formats and color definitions, but this version of pod2fm does not do anything with them.

Paragraph Formats

There are several paragraph formats that pod2fm uses, and there is a mapping from the pod command to the paragraph format that is produced. The exception to the mapping is the =over and =back commands: they modify the paragraph format by shifting its left edge by .1" times the amount in the =over command. You need to take this into account when you are changing the paragraph format. If you drop the size of the font in the format, you do not get a smaller shift. An =over 5 always gives an indent of .5".

The paragraph formats that pod2fm uses are:

pod_TITLE
Paragraphs marked with this format contain the name of the pod. The name is automatically added to the start of each document, and this format is only used here.
You can use the pod_TITLE tag to generate a header or footer with the name of the pod in it by changing the Master Page layout. If you are generating a book, this format is exported so that you can create a Table of Contents by changing the Reference Page.

pod_Body
This format marks a standard paragraph. The left edge moves with each =over n and =back. The edge moves by n times .1".

pod_head1
This format is used for section headers. The command is used like:
=head1 text
where text is printed in this format. The =over and =back commands do not change this format.
If you are generating a book, this format is exported so that you can create a Table of Contents by changing the Reference Page. Also, a marker is placed on the text so that it can be placed in an Index.

pod_head2
This format is used for sub-section headers. The command is used like:
=head2 text
where text is printed in this format. The =over and =back commands do not change this format.
If you are generating a book, this format is exported so that you can create a Table of Contents by changing the Reference Page. Also, a marker is placed on the text so that it can be placed in an Index.

pod_ol
This format is used on ordered (numbered) lists. If the indent command is in this form:
=item n[.]
where n is any number followed by an optional period, the next paragraph is marked with this format and prints as a hanging indent that starts with an automatically generated number and a period. The start of the paragraph is shifted by the amount in the =over command. Any paragraphs that come after the first are marked with pod_Body and the left edge is shifted by the amount from the =over command.

pod_ul
This format is used on unordered lists. If the indent command is in this form:
=item *
the next paragraph is marked with this format and prints as a hanging indent that starts with a bullet. The start of the paragraph is shifted by the amount in the =over command. Any paragraphs that come after the first are marked with pod_Body and the left edge is shifted by the amount from the =over command.

pod_dl
This format is used on description lists. If the indent command is in this form:
=item * text
the text is printed after a bullet, on a line by itself. Any paragraphs that come after the first are marked with pod_Body and the left edge is shifted by the amount from the =over command.

pod_hi
This format is used on hanging indent lists. If the indent command is in this form:
=item text
the text is printed as a hanging indent. The next paragraph is marked with this format and prints with the start of the paragraph shifted by the amount in the =over command. Any paragraphs that come after the first are marked with pod_Body and the left edge is shifted by the amount from the =over command.

pod_il
This format is used on implied lists. If the first line of a paragraph is in this form:
____hang_______text
 |          |
 +- spaces  +- tabs
      or
     tabs
the hang is printed as a hanging indent and the text is printed with the left edge shifted to 2.5" from the current pod_Body left edge. The rest of the lines in the paragraph are treated the same, i.e., each line in the pod's paragraph is converted to a FrameMaker paragraph that is marked with pod_il. Any paragraphs that come after the first are marked with pod_Body and the left edge is shifted by the amount from the =over command.

pod_pre
This format is used on verbatim paragraphs. If the first line of a paragraph is in this form:
____text
 |
 +- spaces
      or
     tabs
the text, including the leading whitespace, is printed with the left edge shifted to the current pod_Body left edge. The rest of the lines in the paragraph are treated the same, i.e., each line in the pod's paragraph is converted to a FrameMaker paragraph that is marked with pod_pre. Any paragraphs that come after the first are marked with pod_Body, and the left edge is shifted by the amount from the =over command.

Table of Contents

If you are producing a book, and you have a -template command-line option, and you are importing the Master Page Layout (-format Page or the default), you can produce a Table of Contents by adding the -toc option. pod2fm automatically adds a generated document called book_nameTOC.doc to the book file, where book_name is the optional argument to the -book command-line option. If no argument is give on the -book, you get a document called perlTOC.doc.

To specify the format of the Table of Contents, you need to go to the reference pages of the template document and create a flow called TOC. Within the flow, create a picture of what the Table of Contents will look like. You can add building blocks to the picture that allow you to control what is printed, e.g., the page number and text for the TOC entry. See the FrameMaker On-Line Help or Using FrameMaker printed manual for a complete description of how to set up a TOC Reference page.

The TOC entry is derived from paragraphs in the documents in the book that are marked with specific paragraph formats. pod2fm uses the paragraph formats pod_TITLE, pod_head1, and pod_head2 to mark the TOC entries.

To make a TOC entry show, you need to create a new paragraph format that tracks the format used in the documents. The new paragraph has the form:

format_nameTOC
where format_name is the format name used in the document. Here is an example of a TOC specification:

Paragraph tagged    Specifies
----------------    ---------
pod_TITLE           <$paratext><$nopage>
pod_head1                  <$paratext>\t<$pagenum>
pod_head2                         <$paratext>\t<$pagenum>
which prints something like this:

POD2FM
    NAME                                    1
    SYNOPSIS                                1
    DESCRIPTION                             1
    OPTIONS                                 1
    TEMPLATES                               3
        Paragraph Formats                   3
        Table of Contents                   5
        Index                               6
    BUGS                                    6
    AUTHORS                                 7

Index

An Index document is much the same as a Table of Contents document: you must be generating a book and importing Reference Page Layouts from a template, and have a -index command-line option.

The format for the Index is also specified on a Reference Page in a flow called IX, and it has its own set of building blocks. Please see the FrameMaker documentation for more details on how to create the Index Reference Page.

pod2fm generates the index from any Index markers that have been placed in the documents. The markers are generated on any =head or =item command and any interior sequences (like I\<\>, B\<\>, and L\<\>) that refer to an =head or =item.

Bugs

fmbatch dies when it tries to work on a Table of Contents or an Index. This happens both in ImportFormats and Update. To get around this, just open the book file in maker and do the Import Formats and Update there.

You can't change the amount of indent using a template file (yet...).

Authors

Based on pod2html. Extended by Mark Pease, Mark_Pease-RXYE0@email.mot.com, for MML. fmbatch and book support added by Tim Bunce, Tim.Bunce@ig.co.uk.

Please send bug reports to Mark Pease.


SelfLoader

  • load functions only on demand

Synopsis

package GoodStuff;
use SelfLoader;

[initializing code]
__DATA__
sub {...};

Description

This module is used for delayed loading of Perl functions that (unlike AutoLoader functions) are packaged within your script file. This gives the appearance of faster loading.

In the example above, SelfLoader tells its user (GoodStuff) that functions in the GoodStuff package are to be autoloaded from after the __DATA__ token.

The __DATA__ token tells Perl that the code for compilation is finished. Everything after the __DATA__ token is available for reading via the filehandle GoodStuff::DATA, where GoodStuff is the name of the current package when the __DATA__ token is reached. This token works just the same as __END__ does in the package main, except that the data after __END__ is retrievable only in package main, whereas data after __DATA__ is retrievable in whatever the current package is.

Note that it is possible to have __DATA__ tokens in the same package in multiple files, and that the last __DATA__ token in a given package that is encountered by the compiler is the one accessible by the filehandle. That is, whenever the __DATA__ token is parsed, any DATA filehandle previously open in the current package (opened in a different file, presumably) is closed so that the new one can be opened. (This also applies to __END__ and the main::DATA filehandle: main::DATA is reopened whenever __END__ is encountered, so any former association is lost.)

SelfLoader Autoloading

The SelfLoader will read from the GoodStuff::DATA filehandle to get definitions for functions placed after __DATA__, and then evaluate the requested subroutine the first time it's called. The costs are the one-time parsing of the data after __DATA__, and a load delay for the first call of any autoloaded function. The benefits are a speeded up compilation phase, with no need to load functions that are never used.

You can use __END__ after __DATA__. The SelfLoader will stop reading from DATA if it encounters the __END__ token, just as you might expect. If the __END__ token is present, and is followed by the token DATA, then the SelfLoader leaves the GoodStuff::DATA filehandle open on the line after that token.

The SelfLoader exports the AUTOLOAD subroutine to the package using the SelfLoader, and this triggers the automatic loading of an undefined subroutine out of its DATA portion the first time that subroutine is called.

There is no advantage to putting subroutines that will always be called after the __DATA__ token.

Autoloading and File-Scoped Lexicals

A my $pack_lexical statement makes the variable $pack_lexical visible only up to the __DATA__ token. That means that subroutines declared elsewhere cannot see lexical variables. Specifically, autoloaded functions cannot see such lexicals (this applies to both the SelfLoader and the AutoLoader). The use vars pragma (see later in this chapter) provides a way to declare package-level globals that will be visible to autoloaded routines.

SelfLoader and AutoLoader

The SelfLoader can replace the AutoLoader--just change use AutoLoader to use SelfLoader[2] and the __END__ token to __DATA__.

There is no need to inherit from the SelfLoader.

The SelfLoader works similarly to the AutoLoader, but picks up the subroutine definitions from after the __DATA__ instead of in the lib/auto/ directory. SelfLoader needs less maintenance at the time the module is installed, since there's no need to run AutoSplit. And it can run faster at load time because it doesn't need to keep opening and closing files to load subroutines. On the other hand, it can run slower because it needs to parse the code after the __DATA__. Details of the AutoLoader and another view of these distinctions can be found in that module's documentation.

How to Read DATA from Your Perl Program

(This section is relevant only if you want to use the GoodStuff::DATA together with the SelfLoader.)

The SelfLoader reads from wherever the current position of the GoodStuff::DATA filehandle is, until EOF or the __END__ token. This means that if you want to use that filehandle (and only if you want to), you should either

    • Put all your subroutine declarations immediately after the __DATA__ token and put your own data after those declarations, using the __END__ token to mark the end of subroutine declarations. You must also ensure that the SelfLoader first reads its stubs by calling SelfLoader->load_stubs();, or by using a function which is selfloaded; or

    • You should read the GoodStuff::DATA filehandle first, leaving the handle open and positioned at the first line of subroutine declarations.

You could even conceivably do both.

Classes and Inherited Methods

This section is only relevant if your module is a class, and has methods that could be inherited.

A subroutine stub (or forward declaration) looks like:

sub stub;
That is, it is a subroutine declaration without the body of the subroutine. For modules that aren't classes, there is no real need for stubs as far as autoloading is concerned.

For modules that are classes, and need to handle inherited methods, stubs are needed to ensure that the method inheritance mechanism works properly. You can load the stubs into the module at require time, by adding the statement SelfLoader->load_stubs(); to the module to do this.

The alternative is to put the stubs in before the __DATA__ token before releasing the module, and for this purpose the Devel::SelfStubber module is available. However this does require the extra step of ensuring that the stubs are in the module. If you do this, we strongly recommended that you do it before releasing the module and not at install time.

Multiple Packages and Fully Qualified Subroutine Names

Subroutines in multiple packages within the same file are supported--but you should note that this requires exporting SelfLoader::AUTOLOAD to every package which requires it. This is done automatically by the SelfLoader when it first loads the subs into the cache, but you should really specify it in the initialization before __DATA__ by putting a use SelfLoader statement in each package.

Fully qualified subroutine names are also supported. For example:

__DATA__
sub foo::bar {23}
package baz;
sub dob {32}
will all be loaded correctly by the SelfLoader, and the SelfLoader will ensure that the packages "foo" and "baz" correctly have the SelfLoader::AUTOLOAD method when the data after __DATA__ is first parsed.

Author

Jack Shirazi, js@biu.icnet.uk

Copyright

Copyright © 1995 Jack Shirazi. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

See Also

AutoLoader


UNIVERSAL

  • default general behavior for all objects

Synopsis

require UNIVERSAL;

$class = $any_object->class();
$bool = $any_object->is_instance();

Description

UNIVERSAL provides general default methods that any object can call.

Methods

->class()

This method returns the class of its object.

->is_instance()

This method returns true if its object is an instance of some class, false if its object is the class (package) itself (i.e., if "A" is a package, then A->is_instance() is false, but $a = bless [],A; $a->is_instance() is true).

Example

The following illustrates the methods, and can be executed using perl -x UNIVERSAL.pm:

#!perl


    require UNIVERSAL;
    package C;
    sub new {bless []}

    package main;
    sub test {
       my($obj,$meth,@args) = @_;
       print $obj,'->',$meth,'(',@args,") gives '",
            join(',',$obj->$meth(@args)),"'\n"
    }
    test(C,'is_instance');                  #C->is_instance()
    test(C->new(),'is_instance');           #C->new()->is_instance()

    test(C,'class');                        #C->class()
    test(C->new(),'class');                 #C->new()->class()  "foo"

__END__

Author

Jack Shirazi, js@biu.icnet.uk

Copyright

Copyright © 1995 Jack Shirazi. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


[1] Perl was written in C, not because it's a portable language, but because it's a ubiquitous language. A bare C program is about as portable as Chuck Yeager on foot.

[2] Be aware, however, that the SelfLoader exports a function into your package. But if you have your own function and are using the AutoLoader too, you probably know what you're doing.

Return to Table of Contents

Copyright 1998, O'Reilly & Associates, Inc.