fileparse is part of
File::Basename<http://perldoc.perl.org/File/Basename.html>,
so it's possible this changed with an update to that module in you perl
environment. The pathname it's complaining about the [statistics]
File_Inin your rmagic.ini file. So first, double check that is still
valid and
hasn't changed. I don't see anything different in File::Basename
documentation than it was ten years ago. It's also possible that something
between the two (e.g. Config::IniFiles parses rmagic.ini) has changed and
is failing.
As a debug step I'd throw a print line in just above 388 in your rmagic.ini
print $statistics{File_In}
That should at least let you know if the path makes any sense to cent OS.
Jeremy Wadsack
On Mon, Jul 16, 2012 at 5:09 PM, Dimitri Maziuk <dmitri.maz...@gmail.com>wrote:
> $ /website/rmagic-2.21/rmagic.pl /website/etc/analog/combined/ftp12.ini
> !!
> fileparse(): need a valid pathname at /website/rmagic-2.21/rmagic.pl line 390
And it's not the best code I've every written either. ;) Honestly, I'm
having trouble following it too.
The $statistics hash is copied from a Config::IniFiles class. It should be
loading values from the ini file and mapping them. You could also try
print $config{statistics}{File_In}
to debug the hash copy. Somehow I'm suspecting that it may be a problem in
Config::IniFiles. If this is also nul, can you check the version of the
library (perl -e 'Config::IniFiles::VERSION' should do it, I think)?
Jeremy Wadsack
On Fri, Jul 27, 2012 at 10:09 AM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> The $statistics hash is copied from a Config::IniFiles class. It should be
> loading values from the ini file and mapping them. You could also try
> print $config{statistics}{File_In}
> to debug the hash copy. Somehow I'm suspecting that it may be a problem in
> Config::IniFiles. If this is also nul, can you check the version of the
> library (perl -e 'Config::IniFiles::VERSION' should do it, I think)?
Yeah. For whatever reason, %config doesn't have any of the loaded data from
the language files or your settings. So I'm pretty certain that it's an
issue with Config::IniFiles.
Shlomi Fish was been maintaining that module for years now, and it's currently
at 2.77 <http://sourceforge.net/projects/config-inifiles/>. The last
version I installed that I know is working is 2.39. That's a lot of
variance.
Can you determine if that was recently updated? That would help decide if
we should look there.
Jeremy Wadsack
On Fri, Jul 27, 2012 at 12:37 PM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> On 07/27/2012 01:30 PM, Jeremy Wadsack wrote:
> ...
> > The $statistics hash is copied from a Config::IniFiles class. It should
> be
> > loading values from the ini file and mapping them. You could also try
> > print $config{statistics}{File_In}
> > to debug the hash copy. Somehow I'm suspecting that it may be a problem
> in
> > Config::IniFiles. If this is also nul, can you check the version of the
> > library (perl -e 'Config::IniFiles::VERSION' should do it, I think)?
I'm not having much luck digging through the fedora build logs to see what
the diff was for that patch. Maybe you know it better? I'm guessing that
patching the temporary file usage broke something that reportmagic uses
that doesn't have a corresponding test case in Config::IniFiles.
Jeremy Wadsack
On Fri, Jul 27, 2012 at 1:38 PM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> I'm not having much luck digging through the fedora build logs to see what
> the diff was for that patch. Maybe you know it better? I'm guessing that
> patching the temporary file usage broke something that reportmagic uses
> that doesn't have a corresponding test case in Config::IniFiles.
I can't even see where rmagic.pl reads its argv[1] into ini hash... :(
Perhaps something in the upstream changelog since 2.72? I can file a bug
report against centos rpm, but having more details than just "broke
report magic" would be useful.
Oh, I agree that "breaks something in reportmagic" is a terrible bug
report. That's why I was looking for the changelog/diff for that update to
see if that could pin it down.
As to where rmagic read ars[1], that's complicated. In
wadg::rm::Settings<https://github.com/jeremywadsack/reportmagic/blob/master/wadg/rm/Sett...>it
read the whole command line around line 79 and assigns anything that
doesn't start with '-' to a list of filenames. Around line 118 it iterates
through the list until it finds one that Config::IniFiles can parse.
Note that if no arguments are given it looks for 'rmagic.ini' in the curent
folder and then in the script's folder (lines 89-108).
BTW, all that traces from line 230 in rmagic.pl.
Does that help any?
Jeremy Wadsack
On Fri, Jul 27, 2012 at 1:57 PM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> > I'm not having much luck digging through the fedora build logs to see
> what
> > the diff was for that patch. Maybe you know it better? I'm guessing that
> > patching the temporary file usage broke something that reportmagic uses
> > that doesn't have a corresponding test case in Config::IniFiles.
> I can't even see where rmagic.pl reads its argv[1] into ini hash... :(
> Perhaps something in the upstream changelog since 2.72? I can file a bug
> report against centos rpm, but having more details than just "broke
> report magic" would be useful.
> As to where rmagic read ars[1], that's complicated. In
> wadg::rm::Settings<https://github.com/jeremywadsack/reportmagic/blob/master/wadg/rm/Sett...>it
> read the whole command line around line 79 and assigns anything that
> doesn't start with '-' to a list of filenames. Around line 118 it iterates
> through the list until it finds one that Config::IniFiles can parse.
...
> Does that help any?
but I don't understand what it means. I thought "tie" was supposed to
intialize %hash to contents of /website/etc/analog/combined/ftp12.ini,
but clearly I thought wrong... like I said, my Perl sucks.
Your Perl is right. (And I'm trying very hard not to write ruby in my
examples back.) It should bind the contents of the file to the hash.
The output is interesting though, because it clearly means that it *is* getting
some of the contents of the file. Each section in the ini file (e.g.
[statistics], [reports], etc.) is being loaded as a key in the hash. What
it's not getting is the settings below that.
I wonder if you can just test Config::IniFiles directly against that file
in a separate perl script.
use Config::IniFiles;
my $cfg = Config::IniFiles->new( -file => "/website/etc/analog/combined/
ftp12.ini" );
print "The source is " . $cfg->val( 'settings', 'File_In' );
tie %hash, 'Config::IniFiles', ( -file => "/website/etc/analog/combined/
ftp12.ini" ) ;
print "The source is " . $hash{settings}{File_In};
Jeremy Wadsack
On Fri, Jul 27, 2012 at 2:38 PM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> On 07/27/2012 04:18 PM, Jeremy Wadsack wrote:
> ..
> > As to where rmagic read ars[1], that's complicated. In
> > wadg::rm::Settings<
> https://github.com/jeremywadsack/reportmagic/blob/master/wadg/rm/Sett... > >it
> > read the whole command line around line 79 and assigns anything that
> > doesn't start with '-' to a list of filenames. Around line 118 it
> iterates
> > through the list until it finds one that Config::IniFiles can parse.
> ...
> > Does that help any?
> but I don't understand what it means. I thought "tie" was supposed to
> intialize %hash to contents of /website/etc/analog/combined/ftp12.ini,
> but clearly I thought wrong... like I said, my Perl sucks.
The reason Settings gets called twice is that it's looking for a default
file because (I think) none was given on the command-line. So it's trying
several options. It bails immediately on 'rmagic.pl' because it knows
that's the program itself and then goes to the next matching file.
I actually don't recall how %{} works in terms of coercing something into a
hash. It also may have changed since I last was really good at Perl. The
thing is, %config isn't *really* a hash, it's a module that's tied to a
hash to make it act like one. So the reason Dump only shows the first
elements (and not the contained hash elements) I think is related to that.
Still I think that `%statistics = %{$config{statistics}};` should work.
Especially since it has worked for at least 10 years or more. Perl 5.x
hasn't changed that much.
If you dump $config{statistics} from rmagic.pl does that iterate the hash
members? It seems that something between the tie and the hash copy is
failing.
Jeremy Wadsack
On Fri, Jul 27, 2012 at 3:57 PM, Dimitri Maziuk <dmaz...@bmrb.wisc.edu>wrote:
> The reason Settings gets called twice is that it's looking for a default
> file because (I think) none was given on the command-line.
Right. It was Friday afternoon, that's my excuse.
> I actually don't recall how %{} works in terms of coercing something into a
> hash. It also may have changed since I last was really good at Perl. The
> thing is, %config isn't *really* a hash, it's a module that's tied to a
> hash to make it act like one.
So I wonder if something inside IniFiles object changed in or around
2.72 to make it not quite work as a hash.
> Still I think that `%statistics = %{$config{statistics}};` should work.
Here's the test case:
> use Config::IniFiles;
> use Data::Dumper;
> $Data::Dumper::Indent = 3;
> tie %hash, 'Config::IniFiles', ( -file => "/website/etc/analog/combined/ftp12.ini" ) ;
> print Dumper(\%hash);
> print "The source is " . $hash{statistics}{File_In};
> print "\n========================================\n";
> %copy = %{ $hash{ statistics } };
> print "The copy is " . $copy{File_In};
> print "\n========================================\n";
and the output:
> $ ./simple.pl
> $VAR1 = {
> 'statistics' => {},
> 'navigation' => {},
> 'reports' => {},
> 'DIRECTORY' => {},
> 'QUICK' => {},
> 'graphs' => {},
> 'website' => {}
> };
> The source is /website/admin/logs/analog_output/ftp/ftp_2012.dat
> ========================================
> Use of uninitialized value in concatenation (.) or string at ./simple.pl line 28.
> The copy is
> ========================================
Looks like a heisenbug to me: worked until I looked at it.
According to RedHat that version of Config::IniFiles requires (but did
not explicitly Require at RPM level) a newer List::MoreUtils (0.33+) to
function properly.
> FYI: the fix is slated for the next epel update.
> According to RedHat that version of Config::IniFiles requires (but did
> not explicitly Require at RPM level) a newer List::MoreUtils (0.33+) to
> function properly.
