Archive for the ‘Perl’ Category

Perl gotcha’s–arrays

Sunday, February 14th, 2016

Working with some existing code to pull data from a MySQL database I ran the following code:

$SQL  = "SELECT id FROM `sensors` ";
$SQL .= "WHERE `storage_table` LIKE '$source_temperature_table' ";

$r = $db->query($SQL);
my $src_sensor_id = $r->getNextRow();
print "The id is $src_sensor_id \n";

No matter which table I ran this on, I always got 1 as the id. So I tried looking at the value of $r using print $r; and the correct ID was showing up. The reason is that perl is different from other languages that I use when it comes to arrays. When I thought I assigned the only value in $r to $src_sensor_id, what I was really doing was assigning the count of the number of rows in $r to $src_sensor_id. When I printed $r, the print statement printed all of the values in the array $r because that’s how print statements handle arrays.

The correct way to assign the array values in $r to variables is to put parentheses around the list of variables in the array. e.g.

my ($src_sensor_id) = $r->getNextRow();

If you have multiple items in the array, separate the variables with commas. e.g.

my ($src_sensor_id, $location, $name) = $r->getNextRow();

Log results of perl scripts

Thursday, December 3rd, 2015

While you are debugging perl scripts, the default for print statements is to display on the console. Often you want to have more info than fits nicely on the console or you want to be able to search through the results. In that case you can redirect the print commands with a simple redirect. e.g.

./ > test_results.txt

Once the script is debugged and running as a cron job, you might still want to see that it has successfully completed or has generated errors. In that case, redirecting the STDOUT and STDERR to log files is what you want to do.

I created a directory /var/log/My_logs and chmodded it to 755 and chowned it to admin. Then I added two lines at the beginning of the file.

#! /usr/bin/perl

use strict;
use warnings;

open(STDOUT, '>>',  $0 . ".log") or die "Can't open log";
open(STDERR, '>>',  $0 . ".error.log") or die "Can't open error log";

A couple of notes. the >> appends the results to the current file. $0 is the name of the perl script that is running. So if I run, the log file is perl_test.l.log. Also note that that is the complete file path and file name. If you are running the script manually, you might want to create log files in the same directory as the script. But if the script is part of a cron job, you might be better off writing the log files to /var/log/. And you probably don’t want the entire script do die if the log file can’t be opened.

An alternative way to do the same thing is to split the file name into parts with the fileparse function in the File::Basename module.

#! /usr/bin/perl

use strict;
use warnings;

 my($filename, $directories, $suffix) = fileparse($path);

open(STDOUT, '>>', "/var/log/My_Project_logs/" . $filename. ".log");
open(STDERR, '>>', "/var/log/My_Project_logs/" . $filename. ".error.log");

If you run the script as you, but later want it to be run as a cron job, make sure you change the permissions of the log files so that they match the permissions of the owner of the script.

If you write out a bunch of stuff, make sure you clean out the log files from time to time. Otherwise, set up a log rotation in /etc/logrotate.d/.

Perl gotcha’s–equality

Monday, November 16th, 2015

If you try to compare strings using ==, and you have included the use warnings pragma, you will get a warning, as in the example below. However, Perl will still attempt to convert the string into a number. If the string starts with numbers, Perl will use these, otherwise the string equates to 0.

So my conditional,

if ($device_id == '5G0E3663') { ... }

compares two zeros and always returns true. Which in my case made bad things happen.
The correct way to compare strings is:

if ($device_id eq '5G0E3663') { ... }

h/t perlmeme.

Well Golly

Atheism Plus

Buy from Amazon