The simple solution to this is to use the XML::Dumper module.

Let’s suppose your data structure looks like this:

%hash_of_hashes = {
    item1 => {
                item1_1       => 'value1_1',
                item1_2       => 'value1_2',
    },
    item2 => {
                item2_1       => 'value2_1',
                item2_2       => 'value2_2',
    },
  };

You can easily convert this into an XML representation using this command:


my $xml_output = XML::Dumper::pl2xml( \%hash_of_hashes );


So you’ll end up with this output:

<perldata>
 <hashref memory_address="0x878e784">
 <item key="item1">
 <hashref memory_address="0x87a8c58">
 <item key="item1_1">value1_1</item>
 <item key="item1_2">value1_2</item>
 </hashref>
 </item>
 <item key="item2">
 <hashref memory_address="0x87a8c61">
 <item key="item2_1">value2_1</item>
 <item key="item2_2">value2_2</item>
 </hashref>
 </item>
 </hashref>
</perldata>

But be aware: You need to pass the hash by reference, imposing the \%hash_of_hashes notation, otherwise you end up with something like this:

<perldata>
 <scalar>item_1</scalar>
 <scalar>item_2</scalar>
</perldata>

It’s so obvious, but I had overlooked that as well in the first attempts

So here’s a snippet, that makes them look neat, so I can work with simple and unified looking device IDs.

Just make sure to fill in your hostnames and the SNMP community.

#!/usr/local/bin/perl -w

foreach $_SITE ('hostname1', 'hostname2', 'hostname3', 'hostname4') {

        my $_cpe_snmp_router_type = `/usr/local/bin/snmpget -v2c -c SNMP_COMMUNITY_NAME $_SITE .1.3.6.1.4.1.9.3.6.11.1.3.1`;

        print "debug: $_snmp_router_type \n";

        if ( $_snmp_router_type =~ /.*=\sSTRING:\s\"[cC]?(\d+[a-zA-Z0-9]+?)(?:\s.*)?\"/ ) {
                print "router type: $1 \n";
        } else {
                print "error: failed on extracting device ID!\n";
        }
}

And here’s what we get as output from this script:

debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "886"

router type: 886
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "887VDSL2"

router type: 887VDSL2
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "c2851 Motherboard with 2GE and integrated VPN"

router type: 2851
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "C836"

router type: 836
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "887VDSL2"

router type: 887VDSL2
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "C836"

router type: 836
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "877"

router type: 877
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "871"

router type: 871
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "1803"

router type: 1803
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "876"

router type: 876

Here’s how to do it with a PIPE:


[gianpaolo@localhost ~]$ cat filename | perl -e 'print reverse <>;'


You can also run it directly on a filename like this:


[gianpaolo@localhost ~]$ perl -e 'print reverse <>;' -f filename


You can do it with ‘sed’ as well:


[gianpaolo@localhost ~]$ cat filename | sed -n '1!G;h;$p'
[gianpaolo@localhost ~]$ sed -n '1!G;h;$p' filename


Personally I favor the Perl method as it’s easier to memorize, despite having more to type
Enjoy!

Before you start digging around using some fancy conversion in Perl, check out the ‘date’ command first.

Here’s a little snippet on how to do it on Linux:


date -u --date="1970-01-01 1285250916 sec GMT"


This will convert your timestamp 1285250916 into it’s date representation of Thu Sep 23 14:08:36 UTC 2010.

As always, there’s slight variations with Linux and BSD userland. To achieve the same on OS X and FreeBSD (maybe other BSDs as well), here’s the appropriate command:


date -j -f %s 1285250916


And for Perl lovers anyway, here is the Perl command


perl -e "print scalar localtime (1285250916)"


As such it’s very easy to capture the output using backticks and use it further on in your scripts. The date command comes in as a last resort especially if you’re working in a restricted environment where higher level languages such as Perl may be unavailable. Though one notices Perl is more versatile than the date command – the later having slight syntactical variations between distributions and vendors propably causing some headache. This opts for the use of Perl if you want to be more platform independent with your script.

FILE.XML:123 parser error : PCDATA invalid Char value 1

While the message itself states clearly that there is an unexpected character value (Char value 1, ASCII SOH) on one hand, it doesn’t tell the character position on the other.

Looking at the input string itself on the console, it wasn’t obvious either:

<EVENT SEVERITY=”Caution” LAST_UPDATE=”08/03/2009 22:20″ INITIAL_UPDATE=”08/03/2009 22:20″ COUNT=”1″ DESCRIPTION=”POST Error: ” />

So I proposed to add some lines to help identify the character position on the given input string, which was basically this:

@array = unpack(“C*”, $_my_input_var);
foreach (@array) {
printf(“char \”%s\” is ord %s\n”, chr($_), $_);
}

This led to the following output:

char “” is ord 62

So looking at this we saw that ASCII char 1 (which is an unprintable character, it will be represented as ^A in some editors like vi) was the fifth character before the end of the string.

Well, basically the solution to this is to apply an additional input filter to remove ASCII char 1 like this:

$_my_input_var =~ s/\x01//g;

While this solves just _this_ problem, a more solid solution is to remove all non-printable characters as well, given the list of ASCII characters at http://www.asciitable.com/.

So a filter like this may apply, removing all non-printable characters, leaving just a few control characters 1×08 to 1x1F (Tab, Carriage Return, Line Feed and a few others) and the printable characters in it.

$_my_input_var =~ s/[\x00-\x08\x0B-\x1F\x7F-\xFF]//g;

File::Tail will be installed without debugging information.
This information isn’t usefull unless you intend to tinker
with the code. To install with debugging enabled, use:
perl Makefile.PL LOGIT
Checking if your kit is complete…
Looks good
Writing Makefile for Mail
==> Your Makefile has been rebuilt. Please rerun the make command. Cleaning for perl-5.8.8
===> Cleaning for p5-File-Tail-0.99.3
===> Vulnerability check disabled, database not found
===> Extracting for p5-File-Tail-0.99.3
=> MD5 Checksum OK for File-Tail-0.99.3.tar.gz.
=> SHA256 Checksum OK for File-Tail-0.99.3.tar.gz.
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Patching for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Applying FreeBSD patches for p5-File-Tail-0.99.3
===> p5-File-Tail-0.99.3 depends on file: /usr/local/bin/perl5.8.8 – found
===> Configuring for p5-File-Tail-0.99.3

File::Tail will be installed without debugging information.
This information isn’t usefull unless you intend to tinker
with the code. To install with debugging enabled, use:
perl Makefile.PL LOGIT
Checking if your kit is complete…
Looks good
Writing Makefile for File::Tail
===> Building for p5-File-Tail-0.99.3
cp Tail.pm blib/lib/File/Tail.pm
Manifying blib/man3/File::Tail.3

So we learn an important lesson from this: Perl’s MakeMaker does not only fail the build process if the system clock is set incorrectly.
It does so also if the timestamps on any source files and MakeMaker’s own perl modules have a time leap forward.

I was just bringing up a new webmail host when I noticed Apache throwing an 500 internal server error at me.

Looking at the error log I saw this line:

[Wed Jan 01 00:16:35 2003] [error] [client 127.0.0.1] Prototype mismatch: sub APR::XSLoader::BOOTSTRAP: none vs () at /usr/local/lib/perl5/site_perl/5.8.8/mach/APR/XSLoader.pm line 24. BEGIN failed–compilation aborted at /usr/local/lib/perl5/site_perl/5.8.8/mach/APR/XSLoader.pm line 26. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.8.8/mach/Apache2/Reload.pm line 161.

At first I though to be going mad because that server had just worked only few hours ago. Why would it fail like that after relocating it?

At second thought I noticed the time stamp which said “Wed Jan 01 00:16:35 2003″.

Well, the server had likely lost it’s CMOS settings during relocation. So after correcting the time through ntpdate the error had disappeared and Apache/mod_perl worked like a charm again.

While there’s a lot of tools out there allowing you to find and replace strings in text files, there’s always a goog reason to use the tools that you already have.

The following snippet uses find in combination with perl to achieve the task:

#find /my/path -type f -exec perl -i -p -e ‘s/search/replace/g;’ {} \;

This command line instructs to find all files within /my/path, passing them to perl, which is instructed to find and replace given strings instantly.

Rememver however that this is not binary safe so you should run this only on directories containt text files.

The get additional verbosity add the ‘-print’ flag to find’s command line to see which files is being worked on.

If you pass an optional extension to ‘-i’ (eg. ‘-i.bak’) perl is instructed to create a backup by the same filename plus extension.

As always: man find and man perl are your friends.

Enjoy!

At first I thought of a bug in the module package itself, but after further inspection I noticed these two lines:

>> Note (probably harmless): No library found for -lclamav
>> ClamAV.xs:11:20: clamav.h: No such file or directory

So at a first glance it would look like libclamav and it’s header file were not installed properly (hence not found), but since it did so only minutes ago there must have been another reason for this error to come up.

Looking at the cc command line I noticed the absence of the usual include statement pointing to /usr/local/include.

To fix this issue we need to know how module compilation actually works in Perl.

Some may be familiar with autoconfig (configure.sh) used with most source tarballs out there. Perl uses a similar approach to bring together it’s build dependencies called MakeMaker (ExtUtils::MakeMaker). Perl module packages usually come along with a MakeMaker prototype file (Makefile.PL) which serves the purpose to build a regurlar Makefile.

MakeMaker relies on Perl’s bootstrap build settings to stick things together, so if anything is missing there errors at compile time may arise.

So we need to check out the Perl configuration files Config.pm and Config_heavy.pl. These are usually found at /usr/local/lib/perl5/x.y.z/mach (x.y.z denotes the Perl version, e.g. 5.8.8. If this does not apply to you, check your ‘perl -V’ output and look at your @INC directories, also [s]locate/find may be of use too).

Let’s look at Config.pm first, locating this line:

libpth=’/usr/lib’,

Change it to to include “/usr/local/lib” (or any lib directory that may apply to your environment) and save the file.

libpth=’/usr/lib /usr/local/lib’,

This will cause MakeMaker to not claim any longer about “No library found for -lclamav”.

Doing the same for the header files does involve a bit of additional work. Let’s check out Config_heavy.pl.
This file contains a lot of settings written out by autoconf during Perl’s initial bootstrap compilation, some of which are used to compile inline code in Perl.

Let’s look at the ccflags/cppflags first:

ccflags=’-DAPPLLIB_EXP=”/usr/local/lib/perl5/5.8.8/BSDPAN” -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe’
cppflags=’-DAPPLLIB_EXP=”/usr/local/lib/perl5/5.8.8/BSDPAN” -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe’

Adding the include directory (/usr/local/include or whatever may apply to you) will cause the header files to be found at compile time:

ccflags=’-DAPPLLIB_EXP=”/usr/local/lib/perl5/5.8.8/BSDPAN” -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include’
cppflags=’-DAPPLLIB_EXP=”/usr/local/lib/perl5/5.8.8/BSDPAN” -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include’

Since compiling usually also involves linking these additional settings must be changed to:

lddlflags=’-shared ‘
ldflags=’ -Wl,-E’
libpth=’/usr/lib’
libspath=’ /usr/lib’

Change the lines to include the library directory (/usr/local/lib in my case) to ensure ld finding all dependencies:

lddlflags=’-shared -L/usr/local/lib’
ldflags=’ -Wl,-E -L/usr/local/lib’
libpth=’/usr/lib /usr/local/lib’
libspath=’ /usr/lib /usr/local/lib’

After applying all these changes I could finally compile and install Mail::ClamAV with success.

After all only one question remains: Why was my Perl config so totally screwed up? But this is another story…