#perl tips

Fix #MillenniumBug or #y2038 Bug in #LInux #Perl

Millennium Bug or y2038 Bug in Unix Machine

This post is dedicated to backend programmers mainly and especially who are involved with *nix machine(s) or Macintosh as well. It is similar to Y2K only where in many older machines, the year 2000 was treated as it starts from 1900 again. This time it is with all 32 bit (4 byte) Unix machines. It can store upto 231 i.e 2147483647. If you try to find…

If the hash key is made up of nothing but letters, digits, and underscores without starting with a digit, you may be able to omit the quote marks. This kind of simple string without quote marks is called a bareword, since it stands alone without quotes. For example, instead of $score{"fred"}, you could write simply $score{fred}.

Another place where hash keys appear is when assigning an entire hash using a list of key-value pairs. The big arrow (=>) is especially useful between a key and a value because (again, only if the key is a bareword) the big arrow quotes it for you: 

# Hash containing bowling scores 

my %score = ( 

  barney   => 195, 

  fred     => 205, 

  dino     => 30, 

); 

my @data = (4.75, 1.5, 2, 1234, 6.9456, 12345678.9, 29.95); 

my @formatted_data = map { &big_money($_) } @data; 

my @odd_numbers; 

foreach (1..1000) { 

  push @odd_numbers, $_ if $_ % 2; 

} 

Since Perl provides the grep operator: 

my @odd_numbers = grep { $_ % 2 } 1..1000; 

How does it work? The first argument to grep is a block that uses $_ as a placeholder for each item in the list, and returns a Boolean (true/false) value. The remaining arguments are the list of items to search through. The grep operator will evaluate the expression once for each item in the list, much as our original foreach loop did. For the ones where the last expression of the block returns a true value, that element is included in the list that results from grep. 

Here we pull only the lines mentioning fred from a file: 

my @matching_lines = grep { /\bfred\b/i } <FILE>; 

There’s a simpler syntax for grep, too. If all you need for the selector is a simple expression (rather than a whole block), you can just use that expression, followed by a comma, in place of the block. Here’s the simpler way to write that latest example: 

Perl provides a simple way to catch fatal errors—wrap the code in an eval block: 

eval { $barney = $fred / $dino } ;   # divide-by-zero error? 

Now, even if $dino is zero, that line won’t crash the program. The eval is actually an expression (not a control structure, like while or foreach), so that semicolon is required at the end of the block.  When a normally fatal error happens during the execution of an eval block, the block is done running, but the program doesn’t crash. So that means that right after an eval finishes, you’ll want to know whether it exited normally or whether it caught a fatal error for you. The answer is in the special $@ variable. If the eval caught a fatal error, $@ will hold what would have been the program’s dying words, perhaps something like: Illegal division by zero at my_program line 12. If there was no error, $@ will be empty. Of course, that means that $@ is a useful Boolean (true/false) value (true if there was an error), so you’ll sometimes see code like this after an eval block: 

print "An error occurred: $@" if $@; 

For example,

foreach my $person (qw/ fred wilma betty barney dino pebbles /) { 

  eval { 

    open FILE, "<$person" 

      or die "Can't open file '$person': $!"; 

    my($total, $count); 

    while (<FILE>) { 

      $total += $_; 

      $count++; 

    } 

    my $average = $total/$count; 

    print "Average for file $person was $average\n"; 

    &do_something($person, $average); 

  }; 

  if ($@) { 

    print "An error occurred ($@), continuing\n"; 

  } 

} 

There are four kinds of problems that eval can’t trap. The first group are the very serious errors that crash Perl itself, such as running out of memory or getting an untrapped signal. Since Perl itself isn’t running, there’s no way it can trap these errors.* Of course, syntax errors inside the eval block are caught at compile time—they’re never returned in $@. 

 The exit operator terminates the program at once, even if it’s called from a subroutine inside an eval block. (This correctly implies that when writing a subroutine, you should use die rather than exit to signal when something goes wrong.) 

The syntax for launching a concurrent (parallel) child process is to put the command as the “filename” for an open call, and either precede or follow the command with a vertical bar, which is the “pipe” character. For that reason, this is often called a piped open. 

open DATE, "date|" or die "cannot pipe from date: $!"; 

open MAIL, "|mail merlyn" or die "cannot pipe to mail: $!"; 

If the output from a command has multiple lines, the scalar use of backquotes returns it as a single long string containing newline characters. However, using the same backquoted string in a list context yields a list containing one line of output per element.

In a scalar context, we get all that at once, which we would then need to split up: 

my $who_text = `who`; 

But in a list context, we automatically get the data broken up by lines: 

Simply create a string using backquotes instead of single or double quotes: 

my $now = `date`;             # grab the output of date 

print "The time is now $now"; # newline already present 

Normally, this date command spits out a string approximately 30 characters long to its standard output, giving the current date and time followed by a newline.When we’ve placed date between backquotes, Perl executes the date command, arranging to capture its standard output as a string value and, in this case, assign it to the $now variable. To get the same result in Perl, we can simply add an additional chomp operation on the result: 

chomp(my $no_newline_now = `date`);