CODEWITHSUNDEEP
perldebuggingtypeglob
Jade Allen
Jade Allen

Reputation: 365

Debugging filehandles from perl open()

Let's pretend I have something like this (forgive the bad perl style - this is Someone Else's Perl.)

#!/usr/bin/perl

my $config_dir = '/var/config';
my $status_file = 'last_update.status';

my $host = shift;
chomp($host);

unless ( $host ) { die "Usage: $0 <hostname>\n"; }

open(STATUS,">$config_dir/$host/$status_file") or die "Could not open $config_dir/$host/$status_file for writing.  Aborting...\n";
print STATUS time() . "\n";
close(STATUS);

It's invoked via commandline like so update_status.pl foo.

What I expect to happen: /var/config/foo/last_update.status contains a current timestamp.

What actually happens: /var/config/foo/last_update.status contains an old timestamp.

Now, the script doesn't die; it completes successfully and returns exit code 0 to bash. This is a Debian Linux box running perl 5.10.1.

So my question is: how can I inspect STATUS? Data::Dumper is not helpful at all.

Thanks.

Upvotes: 0

Views: 317

Answers (2)

ikegami
ikegami

Reputation: 385764

This will be the most reliable.

use Data::Dumper qw( Dumper );

{
   local $Data::Dumper::Useqq = 1;
   local $Data::Dumper::Terse = 1;
   local $Data::Dumper::Indent = 0;
   print(Dumper(readlink("/proc/$$/fd/".fileno(STATUS))), "\n");
}

I doubt the error is with the file name, though. Are you sure you aren't just misinterpreting the timestamp?

 perl -nlE'say "".localtime($_)' /var/config/foo/last_update.status

Another possibility is that you are suffering from buffering, but I don't think that can be the case with the code you posted unless you're using NFS or some other distributed file system.

Upvotes: 0

Tony K.
Tony K.

Reputation: 5605

You sort of already inspected it, in that it is not dying.

It could be that your filesystem has timestamp modification tracking disabled. Look at the output of the mount command, and look at the options on the filesystem.

If you meant the content of the file is wrong (as opposed to the inode mtime), then I'd suggest that perhaps your system time is off or perhaps your timezone environment is different than you expect.

Upvotes: 0

Related Questions