use XML::Simple qw(:strict);
my $ref = XMLin([<xml file or string>] [, <options>]);
my $xml = XMLout($hashref [, <options>]);
Or the object oriented way:
require XML::Simple qw(:strict);
my $xs = XML::Simple->new([<options>]);
my $ref = $xs->XMLin([<xml file or string>] [, <options>]);
my $xml = $xs->XMLout($hashref [, <options>]);
(or see ``SAX SUPPORT'' for 'the SAX way').
Note, in these examples, the square brackets are used to denote optional items not to imply items should be supplied in arrayrefs.
XML::Twig is another excellent alternative.
The major problems with this module are the large number of options (some of which have unfortunate defaults) and the arbitrary ways in which these options interact - often producing unexpected results.
Patches with bug fixes and documentation fixes are welcome, but new features are unlikely to be added.
<config logdir="/var/log/foo/" debugfile="/tmp/foo.debug">
<server name="sahara" osname="solaris" osversion="2.6">
<address>10.0.0.101</address>
<address>10.0.1.101</address>
</server>
<server name="gobi" osname="irix" osversion="6.5">
<address>10.0.0.102</address>
</server>
<server name="kalahari" osname="linux" osversion="2.0.34">
<address>10.0.0.103</address>
<address>10.0.1.103</address>
</server>
</config>
The following lines of code in foo:
use XML::Simple qw(:strict);
my $config = XMLin(undef, KeyAttr => { server => 'name' }, ForceArray => [ 'server', 'address' ]);
will 'slurp' the configuration options into the hashref $config (because no filename or XML string was passed as the first argument to "XMLin()" the name and location of the XML file will be inferred from name and location of the script). You can dump out the contents of the hashref using Data::Dumper:
use Data::Dumper; print Dumper($config);
which will produce something like this (formatting has been adjusted for brevity):
{
'logdir' => '/var/log/foo/',
'debugfile' => '/tmp/foo.debug',
'server' => {
'sahara' => {
'osversion' => '2.6',
'osname' => 'solaris',
'address' => [ '10.0.0.101', '10.0.1.101' ]
},
'gobi' => {
'osversion' => '6.5',
'osname' => 'irix',
'address' => [ '10.0.0.102' ]
},
'kalahari' => {
'osversion' => '2.0.34',
'osname' => 'linux',
'address' => [ '10.0.0.103', '10.0.1.103' ]
}
}
}
Your script could then access the name of the log directory like this:
print $config->{logdir};
similarly, the second address on the server 'kalahari' could be referenced as:
print $config->{server}->{kalahari}->{address}->[1];
Note: If the mapping between the output of Data::Dumper and the print statements above is not obvious to you, then please refer to the 'references' tutorial (AKA: ``Mark's very short tutorial about references'') at perlreftut.
In this example, the "ForceArray" option was used to list elements that might occur multiple times and should therefore be represented as arrayrefs (even when only one element is present).
The "KeyAttr" option was used to indicate that each "<server>" element has a unique identifier in the "name" attribute. This allows you to index directly to a particular server record using the name as a hash key (as shown above).
For simple requirements, that's really all there is to it. If you want to store your XML in a different directory or file, or pass it in as a string or even pass it in via some derivative of an IO::Handle, you'll need to check out ``OPTIONS''. If you want to turn off or tweak the array folding feature (that neat little transformation that produced $config->{server}) you'll find options for that as well.
If you want to generate XML (for example to write a modified version of $config back out as XML), check out "XMLout()".
If your needs are not so simple, this may not be the module for you. In that case, you might want to read ``WHERE TO FROM HERE?''.
The simplest approach is to call these two functions directly, but an optional object oriented interface (see ``OPTIONAL OO INTERFACE'' below) allows them to be called as methods of an XML::Simple object. The object interface can also be used at either end of a SAX pipeline.
"XMLin()" accepts an optional XML specifier followed by zero or more 'name => value' option pairs. The XML specifier can be one of the following:
$ref = XMLin('/etc/params.xml');
Note, the filename '-' can be used to parse from STDIN.
$ref = XMLin(undef, ForceArray => 1);
$ref = XMLin('<opt username="bob" password="flurp" />');
$fh = IO::File->new('/etc/params.xml');
$ref = XMLin($fh);
The "XMLout()" function can also be used to output the XML as SAX events see the "Handler" option and ``SAX SUPPORT'' for more details).
When translating hashes to XML, hash keys which have a leading '-' will be silently skipped. This is the approved method for marking elements of a data structure which should be ignored by "XMLout". (Note: If these items were not skipped the key names would be emitted as element or attribute names with a leading '-' which would not be valid XML).
Names in XML must begin with a letter. The remaining characters may be letters, digits, hyphens (-), underscores (_) or full stops (.). It is also allowable to include one colon (:) in an element name but this should only be used when working with namespaces (XML::Simple can only usefully work with namespaces when teamed with a SAX Parser).
You can use other punctuation characters in hash values (just not in hash keys) however XML::Simple does not support dumping binary data.
If you break these rules, the current implementation of "XMLout()" will simply emit non-compliant XML which will be rejected if you try to read it back in. (A later version of XML::Simple might take a more proactive approach).
Note also that although you can nest hashes and arrays to arbitrary levels, circular data structures are not supported and will cause "XMLout()" to die.
If you wish to 'round-trip' arbitrary data structures from Perl to XML and back to Perl, then you should probably disable array folding (using the KeyAttr option) both with "XMLout()" and with "XMLin()". If you still don't get the expected results, you may prefer to use XML::Dumper which is designed for exactly that purpose.
Refer to ``WHERE TO FROM HERE?'' if "XMLout()" is too simple for your needs.
If you can't be bothered reading the documentation, refer to ``STRICT MODE'' to automatically catch common mistakes.
Because there are so many options, it's hard for new users to know which ones are important, so here are the two you really need to know about:
The option name headings below have a trailing 'comment' - a hash followed by two pieces of metadata:
'important' - don't use the module until you understand this one
'handy' - you can skip this on the first time through
'advanced' - you can skip this on the second time through
'SAX only' - don't worry about this unless you're using SAX (or
alternatively if you need this, you also need SAX)
'seldom used' - you'll probably never use this unless you were the
person that requested the feature
The options are listed alphabetically:
Note: option names are no longer case sensitive so you can use the mixed case versions shown here; all lower case as required by versions 2.03 and earlier; or you can add underscores between the words (eg: key_attr).
When parsing from a named file, XML::Simple supports a number of caching schemes. The 'Cache' option may be used to specify one or more schemes (using an anonymous array). Each scheme will be tried in turn in the hope of finding a cached pre-parsed representation of the XML file. If no cached copy is found, the file will be parsed and the first cache scheme in the list will be used to save a copy of the results. The following cache schemes have been implemented:
Because each caller receives a reference to the same data structure, a change made by one caller will be visible to all. For this reason, the reference returned should be treated as read-only.
Warning! The memory-based caching schemes compare the timestamp on the file to the time when it was last parsed. If the file is stored on an NFS filesystem (or other network share) and the clock on the file server is not exactly synchronised with the clock where your script is run, updates to the source XML file may appear to be ignored.
XMLin('<opt one="1">Text</opt>', ContentKey => 'text')
will parse to:
{ 'one' => 1, 'text' => 'Text' }
instead of:
{ 'one' => 1, 'content' => 'Text' }
"XMLout()" will also honour the value of this option when converting a hashref to XML.
You can also prefix your selected key name with a '-' character to have "XMLin()" try a little harder to eliminate unnecessary 'content' keys after array folding. For example:
XMLin(
'<opt><item name="one">First</item><item name="two">Second</item></opt>',
KeyAttr => {item => 'name'},
ForceArray => [ 'item' ],
ContentKey => '-content'
)
will parse to:
{
'item' => {
'one' => 'First'
'two' => 'Second'
}
}
rather than this (without the '-'):
{
'item' => {
'one' => { 'content' => 'First' }
'two' => { 'content' => 'Second' }
}
}
<opt>
<name>value</name>
</opt>
would parse to this:
{
'name' => [
'value'
]
}
instead of this (the default):
{
'name' => 'value'
}
This option is especially useful if the data structure is likely to be written back out as XML and the default behaviour of rolling single nested elements up into attributes is not desirable.
If you are using the array folding feature, you should almost certainly enable this option. If you do not, single nested elements will not be parsed to arrays and therefore will not be candidates for folding to a hash. (Given that the default value of 'KeyAttr' enables array folding, the default value of this option should probably also have been enabled too - sorry).
It is also possible (since version 2.05) to include compiled regular expressions in the list - any element names which match the pattern will be forced to arrays. If the list contains only a single regex, then it is not necessary to enclose it in an arrayref. Eg:
ForceArray => qr/_list$/
XMLin('<opt><x>text1</x><y a="2">text2</y></opt>', ForceContent => 1)
will parse to:
{
'x' => { 'content' => 'text1' },
'y' => { 'a' => 2, 'content' => 'text2' }
}
instead of:
{
'x' => 'text1',
'y' => { 'a' => 2, 'content' => 'text2' }
}
<opt>
<searchpath>
<dir>/usr/bin</dir>
<dir>/usr/local/bin</dir>
<dir>/usr/X11/bin</dir>
</searchpath>
</opt>
Would normally be read into a structure like this:
{
searchpath => {
dir => [ '/usr/bin', '/usr/local/bin', '/usr/X11/bin' ]
}
}
But when read in with the appropriate value for 'GroupTags':
my $opt = XMLin($xml, GroupTags => { searchpath => 'dir' });
It will return this simpler structure:
{
searchpath => [ '/usr/bin', '/usr/local/bin', '/usr/X11/bin' ]
}
The grouping element ("<searchpath>" in the example) must not contain any attributes or elements other than the grouped element.
You can specify multiple 'grouping element' to 'grouped element' mappings in the same hashref. If this option is combined with "KeyAttr", the array folding will occur first and then the grouped element names will be eliminated.
"XMLout" will also use the grouptag mappings to re-introduce the tags around the grouped elements. Beware though that this will occur in all places that the 'grouping tag' name occurs - you probably don't want to use the same name for elements as well as attributes.
Note: the current implementation of this option generates a string of XML and uses a SAX parser to translate it into SAX events. The normal encoding rules apply here - your data must be UTF8 encoded unless you specify an alternative encoding via the 'XMLDecl' option; and by the time the data reaches the handler object, it will be in UTF8 form regardless of the encoding you supply. A future implementation of this option may generate the events directly.
$config = XMLin('<config tempdir="/tmp" />', KeepRoot => 1)
You'll be able to reference the tempdir as "$config->{config}->{tempdir}" instead of the default "$config->{tempdir}".
Similarly, setting the 'KeepRoot' option to '1' will tell "XMLout()" that the data structure already contains a root element name and it is not necessary to add another.
For example, this XML:
<opt>
<user login="grep" fullname="Gary R Epstein" />
<user login="stty" fullname="Simon T Tyson" />
</opt>
would, by default, parse to this:
{
'user' => [
{
'login' => 'grep',
'fullname' => 'Gary R Epstein'
},
{
'login' => 'stty',
'fullname' => 'Simon T Tyson'
}
]
}
If the option 'KeyAttr => ``login''' were used to specify that the 'login' attribute is a key, the same XML would parse to:
{
'user' => {
'stty' => {
'fullname' => 'Simon T Tyson'
},
'grep' => {
'fullname' => 'Gary R Epstein'
}
}
}
The key attribute names should be supplied in an arrayref if there is more than one. "XMLin()" will attempt to match attribute names in the order supplied. "XMLout()" will use the first attribute name supplied when 'unfolding' a hash into an array.
Note 1: The default value for 'KeyAttr' is ['name', 'key', 'id']. If you do not want folding on input or unfolding on output you must set this option to an empty list to disable the feature.
Note 2: If you wish to use this option, you should also enable the "ForceArray" option. Without 'ForceArray', a single nested element will be rolled up into a scalar rather than an array and therefore will not be folded (since only arrays get folded).
Note: "XMLin()" will generate a warning (or a fatal error in ``STRICT MODE'') if this syntax is used and an element which does not have the specified key attribute is encountered (eg: a 'package' element without an 'id' attribute, to use the example above). Warnings can be suppressed with the lexical "no warnings;" pragma or "no warnings 'XML::Simple';".
Two further variations are made possible by prefixing a '+' or a '-' character to the attribute name:
The option 'KeyAttr => { user => ``+login'' }' will cause this XML:
<opt>
<user login="grep" fullname="Gary R Epstein" />
<user login="stty" fullname="Simon T Tyson" />
</opt>
to parse to this data structure:
{
'user' => {
'stty' => {
'fullname' => 'Simon T Tyson',
'login' => 'stty'
},
'grep' => {
'fullname' => 'Gary R Epstein',
'login' => 'grep'
}
}
}
The '+' indicates that the value of the key attribute should be copied rather than moved to the folded hash key.
A '-' prefix would produce this result:
{
'user' => {
'stty' => {
'fullname' => 'Simon T Tyson',
'-login' => 'stty'
},
'grep' => {
'fullname' => 'Gary R Epstein',
'-login' => 'grep'
}
}
}
As described earlier, "XMLout" will ignore hash keys starting with a '-'.
When used with "XMLin()", any attributes in the XML will be ignored.
* Actually, sorting is alphabetical but 'key' attribute or element names (as in 'KeyAttr') sort first. Also, when a hash of hashes is 'unfolded', the elements are sorted alphabetically by the value of the key field.
Note: you can spell this option with a 'z' if that is more natural for you.
By default, "XMLin()" will return element names and attribute names exactly as they appear in the XML. Setting this option to 1 will cause all element and attribute names to be expanded to include their namespace prefix.
Note: You must be using a SAX parser for this option to work (ie: it does not work with XML::Parser).
This option also controls whether "XMLout()" performs the reverse translation from '{uri}name' back to 'prefix:name'. The default is no translation. If your data contains expanded names, you should set this option to 1 otherwise "XMLout" will emit XML which is not well formed.
Note: You must have the XML::NamespaceSupport module installed if you want "XMLout()" to translate URIs back to prefixes.
0 - default: no numeric escaping (OK if you're writing out UTF8)
1 - only characters above 0xFF are escaped (ie: characters in the 0x80-FF range are not escaped), possibly useful with ISO8859-1 output
2 - all characters above 0x7F are escaped (good for plain ASCII output)
This option also accepts an IO handle object - especially useful in Perl 5.8.0 and later for output using an encoding other than UTF-8, eg:
open my $fh, '>:encoding(iso-8859-1)', $path or die "open($path): $!"; XMLout($ref, OutputFile => $fh);
Note, XML::Simple does not require that the object you pass in to the OutputFile option inherits from IO::Handle - it simply assumes the object supports a "print" method.
This option allows you to pass parameters to the constructor of the underlying XML::Parser object (which of course assumes you're not using SAX).
Specifying either undef or the empty string for the RootName option will produce XML with no root elements. In most cases the resulting XML fragment will not be 'well formed' and therefore could not be read back in by "XMLin()". Nevertheless, the option has been found to be useful in certain circumstances.
If a filename is provided to "XMLin()" but SearchPath is not defined, the file is assumed to be in the current directory.
If the first parameter to "XMLin()" is undefined, the default SearchPath will contain only the directory in which the script itself is located. Otherwise the default SearchPath will be empty.
The option also controls what "XMLout()" does with undefined values. Setting the option to undef causes undefined values to be output as empty elements (rather than empty attributes), it also suppresses the generation of warnings about undefined values. Setting the option to a true value (eg: 1) causes undefined values to be skipped altogether on output.
<opt>
<colour value="red" />
<size value="XXL" />
</opt>
Setting "ValueAttr => [ 'value' ]" will cause the above XML to parse to:
{
colour => 'red',
size => 'XXL'
}
instead of this (the default):
{
colour => { value => 'red' },
size => { value => 'XXL' }
}
Note: This form of the ValueAttr option is not compatible with "XMLout()" - since the attribute name is discarded at parse time, the original XML cannot be reconstructed.
Note: You probably don't want to use this option and the NoAttr option at the same time.
A 'variable' is any text of the form "${name}" which occurs in an attribute value or in the text content of an element. If 'name' matches a key in the supplied hashref, "${name}" will be replaced with the corresponding value from the hashref. If no matching key is found, the variable will not be replaced. Names must match the regex: "[\w.]+" (ie: only 'word' characters and dots are allowed).
XMLin( '<opt>
<dir name="prefix">/usr/local/apache</dir>
<dir name="exec_prefix">${prefix}</dir>
<dir name="bindir">${exec_prefix}/bin</dir>
</opt>',
VarAttr => 'name', ContentKey => '-content'
);
produces the following data structure:
{
dir => {
prefix => '/usr/local/apache',
exec_prefix => '/usr/local/apache',
bindir => '/usr/local/apache/bin',
}
}
<?xml version='1.0' standalone='yes'?>
If you want some other string (for example to declare an encoding value), set the value of this option to the complete string you require.
The default values for the options described above are unlikely to suit everyone. The OO interface allows you to effectively override XML::Simple's defaults with your preferred values. It works like this:
First create an XML::Simple parser object with your preferred defaults:
my $xs = XML::Simple->new(ForceArray => 1, KeepRoot => 1);
then call "XMLin()" or "XMLout()" as a method of that object:
my $ref = $xs->XMLin($xml); my $xml = $xs->XMLout($ref);
You can also specify options when you make the method calls and these values will be merged with the values specified when the object was created. Values specified in a method call take precedence.
Note: when called as methods, the "XMLin()" and "XMLout()" routines may be called as "xml_in()" or "xml_out()". The method names are aliased so the only difference is the aesthetics.
For example, you might implement a new 'dbm' scheme that stores cached data structures using the MLDBM module. First, you would add a "cache_read_dbm()" method which accepted a filename for use as a lookup key and returned a data structure on success, or undef on failure. Then, you would implement a "cache_read_dbm()" method which accepted a data structure and a filename.
You would use this caching scheme by specifying the option:
Cache => [ 'dbm' ]
use XML::Simple qw(:strict);
the following common mistakes will be detected and treated as fatal errors
In a typical SAX application, an XML parser (or SAX 'driver') module generates SAX events (start of element, character data, end of element, etc) as it parses an XML document and a 'handler' module processes the events to extract the required data. This simple model allows for some interesting and powerful possibilities:
XML::Simple can operate at either end of a SAX pipeline. For example, you can take a data structure in the form of a hashref and pass it into a SAX pipeline using the 'Handler' option on "XMLout()":
use XML::Simple;
use Some::SAX::Filter;
use XML::SAX::Writer;
my $ref = {
.... # your data here
};
my $writer = XML::SAX::Writer->new();
my $filter = Some::SAX::Filter->new(Handler => $writer);
my $simple = XML::Simple->new(Handler => $filter);
$simple->XMLout($ref);
You can also put XML::Simple at the opposite end of the pipeline to take advantage of the simple 'tree' data structure once the relevant data has been isolated through filtering:
use XML::SAX;
use Some::SAX::Filter;
use XML::Simple;
my $simple = XML::Simple->new(ForceArray => 1, KeyAttr => ['partnum']);
my $filter = Some::SAX::Filter->new(Handler => $simple);
my $parser = XML::SAX::ParserFactory->parser(Handler => $filter);
my $ref = $parser->parse_uri('some_huge_file.xml');
print $ref->{part}->{'555-1234'};
You can build a filter by using an XML::Simple object as a handler and setting its DataHandler option to point to a routine which takes the resulting tree, modifies it and sends it off as SAX events to a downstream handler:
my $writer = XML::SAX::Writer->new();
my $filter = XML::Simple->new(
DataHandler => sub {
my $simple = shift;
my $data = shift;
# Modify $data here
$simple->XMLout($data, Handler => $writer);
}
);
my $parser = XML::SAX::ParserFactory->parser(Handler => $filter);
$parser->parse_uri($filename);
Note: In this last example, the 'Handler' option was specified in the call to "XMLout()" but it could also have been specified in the constructor.
XML::Simple will default to using a SAX parser if one is available or XML::Parser if SAX is not available.
You can dictate which parser module is used by setting either the environment variable 'XML_SIMPLE_PREFERRED_PARSER' or the package variable $XML::Simple::PREFERRED_PARSER to contain the module name. The following rules are used:
Note: The XML::SAX distribution includes an XML parser written entirely in Perl. It is very portable but it is not very fast. You should consider installing XML::LibXML or XML::SAX::Expat if they are available for your platform.
If dying is not appropriate for your application, you should arrange to call "XMLin()" in an eval block and look for errors in $@. eg:
my $config = eval { XMLin() };
PopUpMessage($@) if($@);
Note, there is a common misconception that use of eval will significantly slow down a script. While that may be true when the code being eval'd is in a string, it is not true of code like the sample above.
<opt username="testuser" password="frodo"></opt>
it returns the following data structure:
{
'username' => 'testuser',
'password' => 'frodo'
}
The identical result could have been produced with this alternative XML:
<opt username="testuser" password="frodo" />
Or this (although see 'ForceArray' option for variations):
<opt>
<username>testuser</username>
<password>frodo</password>
</opt>
Repeated nested elements are represented as anonymous arrays:
<opt>
<person firstname="Joe" lastname="Smith">
<email>joe@smith.com</email>
<email>jsmith@yahoo.com</email>
</person>
<person firstname="Bob" lastname="Smith">
<email>bob@smith.com</email>
</person>
</opt>
{
'person' => [
{
'email' => [
'joe@smith.com',
'jsmith@yahoo.com'
],
'firstname' => 'Joe',
'lastname' => 'Smith'
},
{
'email' => 'bob@smith.com',
'firstname' => 'Bob',
'lastname' => 'Smith'
}
]
}
Nested elements with a recognised key attribute are transformed (folded) from an array into a hash keyed on the value of that attribute (see the "KeyAttr" option):
<opt>
<person key="jsmith" firstname="Joe" lastname="Smith" />
<person key="tsmith" firstname="Tom" lastname="Smith" />
<person key="jbloggs" firstname="Joe" lastname="Bloggs" />
</opt>
{
'person' => {
'jbloggs' => {
'firstname' => 'Joe',
'lastname' => 'Bloggs'
},
'tsmith' => {
'firstname' => 'Tom',
'lastname' => 'Smith'
},
'jsmith' => {
'firstname' => 'Joe',
'lastname' => 'Smith'
}
}
}
The <anon> tag can be used to form anonymous arrays:
<opt>
<head><anon>Col 1</anon><anon>Col 2</anon><anon>Col 3</anon></head>
<data><anon>R1C1</anon><anon>R1C2</anon><anon>R1C3</anon></data>
<data><anon>R2C1</anon><anon>R2C2</anon><anon>R2C3</anon></data>
<data><anon>R3C1</anon><anon>R3C2</anon><anon>R3C3</anon></data>
</opt>
{
'head' => [
[ 'Col 1', 'Col 2', 'Col 3' ]
],
'data' => [
[ 'R1C1', 'R1C2', 'R1C3' ],
[ 'R2C1', 'R2C2', 'R2C3' ],
[ 'R3C1', 'R3C2', 'R3C3' ]
]
}
Anonymous arrays can be nested to arbitrary levels and as a special case, if the surrounding tags for an XML document contain only an anonymous array the arrayref will be returned directly rather than the usual hashref:
<opt>
<anon><anon>Col 1</anon><anon>Col 2</anon></anon>
<anon><anon>R1C1</anon><anon>R1C2</anon></anon>
<anon><anon>R2C1</anon><anon>R2C2</anon></anon>
</opt>
[
[ 'Col 1', 'Col 2' ],
[ 'R1C1', 'R1C2' ],
[ 'R2C1', 'R2C2' ]
]
Elements which only contain text content will simply be represented as a scalar. Where an element has both attributes and text content, the element will be represented as a hashref with the text content in the 'content' key (see the "ContentKey" option):
<opt>
<one>first</one>
<two attr="value">second</two>
</opt>
{
'one' => 'first',
'two' => { 'attr' => 'value', 'content' => 'second' }
}
Mixed content (elements which contain both text content and nested elements) will be not be represented in a useful way - element order and significant whitespace will be lost. If you need to work with mixed content, then XML::Simple is not the right tool for your job - check out the next section.
In a serious XML project, you'll probably outgrow these assumptions fairly quickly. This section of the document used to offer some advice on choosing a more powerful option. That advice has now grown into the 'Perl-XML FAQ' document which you can find at: <http://perl-xml.sourceforge.net/faq/>
The advice in the FAQ boils down to a quick explanation of tree versus event based parsers and then recommends:
For event based parsing, use SAX (do not set out to write any new code for XML::Parser's handler API - it is obsolete).
For tree-based parsing, you could choose between the 'Perlish' approach of XML::Twig and more standards based DOM implementations - preferably one with XPath support such as XML::LibXML.
To generate documents with namespaces, XML::NamespaceSupport is required.
The optional caching functions require Storable.
Answers to Frequently Asked Questions about XML::Simple are bundled with this distribution as: XML::Simple::FAQ
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.