Inline::Files unopened filehandle errors redux

[NateTut]

Well it's late on a Friday and I'm stuck. I'm trying to get Inline::Files to work and I am frustrated. I have boiled it down to the example below. Basically if you read from the virtual file and then try to write to it you get:

print() on unopened filehandle CONFIG at Change__DATA__.pl line 26.

Otherwise it works as advertized. I have tried it on Windoze & Solaris with the same results.

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;
use Inline::Files -backup;

my $Config;

if(defined($ARGV[0]) and $ARGV[0] eq 'NoRead')
   {
   $Config->{'Foo'} = 1;
   }
else
   {
   $Config = eval join "", <CONFIG>;
   }

local $Data::Dumper::Useqq  = 1;
local $Data::Dumper::Indent = 1;

$Config->{'Foo'}++;
print Data::Dumper->Dump([$Config],['Config']);

seek CONFIG, 0, 0;
print CONFIG Data::Dumper->Dump([$Config],['Config']);

__CONFIG__
$Config = {
  "Foo" => 2
};

[BrowserUk]

Your question is answered (obliquely) by reading the section of the POD entitled "Writable virtual files".

By default, the virtual files are opened in readonly mode, and when you read past the EOF, they are closed. It is not enough to just rewind (seek FILE, 0, 0;), you also need to re-open the file for write or read-write access.

This is not a complete answer, The affect of the above is to cause multiple __CONFIG__ sections to be written. I think that is a bug. I think the module suffers a severe lack of maintenance.

[NateTut]

I saw that, but when I try to re-open the virtual file I get:



Variable "$CONFIG" is not imported at Change__DATA__.pl line 25.
Global symbol "$CONFIG" requires explicit package name at Change__DATA
+__.pl line 25.
Execution of Change__DATA__.pl aborted due to compilation errors.


I have tried various tricks to get it to open to no avail. The weird thing is that if it only reads one line you can still write.

[BrowserUk]

but when I try to re-open the virtual file I get: Variable "$CONFIG" is not imported

Yes. That's what I get with 5.10 also. It never used to happen. From mmeory, it worked correctly circa 5.8.1|2£|4|5'ish. But my memory is fallible and I don't have the capacity to test that aassertion.

I tried adding our $CONFIG; at the top of the file and that changes the problem to:

Use of uninitialized value $CONFIG in concatenation (.) or string

But doesn't fix it entirley.

Like I said, I think that it suffers from a lack of ongoing maintenance. As with s many of theDamian's modules.