Text::Embed - Cleanly seperate unwieldy text from your source code


    use Text::Embed
    use Text::Embed CODE|REGEX|SCALAR
    use Text::Embed CODE|REGEX|SCALAR, LIST


Code often requires chunks of text to operate - chunks not large enough to warrant extra file dependencies, but enough to make using quotes and heredocs' ugly.

A typical example might be code generators. The text itself is code, and as such is difficult to differentiate and maintain when it is embedded inside more code. Similarly, CGI scripts often include embedded HTML or SQL templates.

Text::Embed provides the programmer with a flexible way to store these portions of text in their namespace's __DATA__ handle - away from the logic - and access them through the package variable %DATA.


General Usage:

The general usage is expected to be suitable for a majority of cases:

    use Text::Embed;

    foreach(keys %DATA)
        print "$_ = $DATA{$_}\n";

    print $DATA{foo};


    yadda yadda yadda...


    ee-aye ee-aye oh

    woof woof

Custom Usage:

There are two stages to Text::Embed's execution - corresponding to the first and remaining arguments in its invocation.

    use Text::Embed ( 
        sub{ ... },  # parse key/values from DATA 
        sub{ ... },  # process pairs
        ...          # process pairs




Stage 1: Parsing

By default, Text::Embed uses similar syntax to the __DATA__ token to seperate segments - a line consisting of two underscores surrounding an identifier. Of course, a suitable syntax depends on the text being embedded.

A REGEX or CODE reference can be passed as the first argument - in order to gain finer control of how __DATA__ is parsed:

    use Text::Embed qr(<<<<<<<<(\w*?)>>>>>>>>);

A regular expression will be used in a call to split(). Any leading or trailing empty strings will be removed automatically.

    use Text::Embed sub{$_ = shift; ...}
    use Text::Embed &Some::Other::Function;

A subroutine will be passed a reference to the __DATA__ string. It should return a LIST of key-value pairs.

In the name of laziness, Text::Embed provides a couple of predefined formats:


Line-oriented __DATA__ like format:

    baz baz baz
    foo foo foo
    foo foo foo

CPP-like format (%DATA is readonly - can be used to define constants):

    #define BAZ     baz baz baz
    #define FOO     foo foo foo
                    foo foo foo

Line-agnostic CDATA-like format. Anything outside of tags is ignored.

    <![BAZ[baz baz baz]]>
        foo foo foo
        foo foo foo

Stage 2: Processing

After parsing, each key-value pair can be further processed by an arbitrary number of callbacks.

A common usage of this might be controlling how whitespace is represented in each segment. Text::Embed provides some likely defaults which operate on the hash values only.


Removes trailing or leading whitespace


Substitutes zero or more whitspace with a single <SPACE>


Removes trailing or leading blank lines, preserves all indentation


Removes trailing or leading blank lines, preserves unique indentation


Leave untouched


Same as :raw

If you need more control, CODE references or named subroutines can be invoked as necessary. At this point it is safe to rename or modify keys. Undefining a key removes the entry from %DATA.

An Example Callback chain

For the sake of brevity, consider a module that has some embedded SQL. We can implement a processing callback that will prepare each statement, leaving %DATA full of ready to execute DBI statement handlers:

    package Whatever;

    use DBI;
    use Text::Embed(':default', ':trim', 'prepare_sql');

    my $dbh;

    sub prepare_sql
        my ($k, $v) = @_;
            $dbh = DBI->connect(...);
        $$v = $dbh->prepare($$v);

    sub get_widget
        my $id  = shift;
        my $sql = $DATA{select_widget};


        SELECT * FROM widgets WHERE widget_id = ?;

        INSERT INTO widgets (widget_id,desc, price) VALUES (?,?,?);


Notice that each pair is passed by reference.

Utility Functions

Several utility functions are available to aid implementing custom processing handlers. These are not exported into the callers namespace.

The first are equivalent to the default processing options:

Text::Embed::trim SCALARREF
    use Text::Embed(':default',':trim');
    use Text::Embed(':default', sub {Text::Embed::trim($_[1]);} );
Text::Embed::compress SCALARREF
    use Text::Embed(':default',':compress');
    use Text::Embed(':default', sub {Text::Embed::compress($_[1]);} );
Text::Embed::block SCALARREF BOOLEAN
    use Text::Embed(':default',':block-indent');
    use Text::Embed(':default', sub {Text::Embed::block($_[1]);} );

If a true value is passed as the second argument, then shared indentation is removed, ie :block-noindent.


If comments would make your segments easier to manage, Text::Embed provides defaults handlers for stripping common comment syntax - :strip-perl, :strip-c, :strip-cpp, :strip-xml.

Text::Embed::strip SCALARREF [REGEX] [REGEX]
    use Text::Embed(':default',':strip-c');
    use Text::Embed(':default', sub {Text::Embed::strip($_[1], '/\*', '\*/');} );

Strips all sequences between second and third arguments. The default arguments are '#' and '\n' respectively.


Typically, embedded text may well be some kind of template. Text::Embed provides rudimentary variable interpolation for simple templates. The default variable syntax is of the form $(foo):

Text::Embed::interpolate SCALARREF HASHREF [REGEX]
    my $tmpl = "Hello $(name)! Your age is $(age)\n";
    my %vars = (name => 'World', age => 4.5 * (10 ** 9));
    Text::Embed::interpolate(\$tmpl, \%vars);
    print $tmpl;

Any interpolation is done via a simple substitution. An additional regex argument should accomodate this appropriately, by capturing the necessary hashkey in $1:

    Text::Embed::interpolate(\$tmpl, \%vars, '<%(\S+)%>');


The most likely bugs related to using this module should manifest themselves as bad key/value error messages. There are two related causes:


It is important to realise that Text::Embed does not have its own comment syntax or preprocessor. Any parser that works using split() is likely to fail if comments precede the first segment. Comments should exist in the body of a segment - not preceding it.


If you are defining your own REGEX parser, make sure you understand how it works when used with split() - particularly if your syntax wraps your data. Consider using a subroutine for anything non-trivial.

If you employ REGEX parsers, use seperators that are significantly different - and well spaced - from your data, rather than relying on complicated regular expressions to escape pathological cases.

Bug reports and suggestions are most welcome.


Copyright (C) 2005 Chris McEwan - All rights reserved.

Chris McEwan <>


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