unusual behaviour with Inline-Files and IO-Handle

Peamasii has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks, I have a script which has been running fine on another system that was retired last week. We have a new system which is very similar and where I installed all the required modules. However on this system I have problems using IO:Handle and Inline::Files. See code below of the test case which fails. Any help is appreciated, I've been spending hours trying to figure out why it fails, granted I'm no perl expert. The runtime error is: Bad file descriptor at io.pl line 19.

#!/usr/bin/perl
use Inline::Files;
use IO::Handle;

sub headerprint {

print "headerprint";
}

sub indexsectionprint {
        my $sectiontitle = shift(@_);
        my $datatitle = shift(@_);
        my $indextitle = lc $sectiontitle;
        my $fh;
  $indextitle =~ s/ /_/g;
  $file = "index." . $indextitle . ".html";
  print STDERR $file,"\n";
  open OUTPUT, '>', "index.network.html" or die "Can't open section fi
+le: $!";
STDOUT->fdopen( \*OUTPUT, 'w' ) or die $!;
headerprint();
}
indexsectionprint("Network", $NETWORK);

__NETWORK__
test
[download]

Comment on unusual behaviour with Inline-Files and IO-Handle Download Code

Replies are listed 'Best First'.
Re: unusual behaviour with Inline-Files and IO-Handle by kcott (Archbishop) on Dec 07, 2015 at 18:21 UTC
G'day Peamasii, "We have a new system which is very similar and where I installed all the required modules." There is a small problem (it looks like it's just a typo) with this module on CPAN that others have fallen foul of: perhaps it's snagged you also. The module Inline::File is part of the `Inline-Files-0.62` distribution and starts with this code: `package Inline::Files; $VERSION = '0.62';` [download] The module Inline::Files is part of the `Inline-Files-0.69` distribution and starts with this code: `package Inline::Files; $VERSION = '0.69';` [download] So, regardless of whether you attempted to install `Inline::File` or `Inline::Files`, the output would show `Inline::Files` being installed. Unless you'd paid particular attention to the version number, it's unlikely you would have noticed the difference. This is the problem others have encountered in the past. If any code with "`use Inline::Files`" is working differently to how it did elsewhere, the first thing I check is the version. You may need to install a different version; although, in general, the newer version is preferable. — Ken	[reply] [d/l] [select]
Re: unusual behaviour with Inline-Files and IO-Handle (select) by Anonymous Monk on Dec 07, 2015 at 16:09 UTC
Any help is appreciated, I've been spending hours trying to figure out why it fails, granted I'm no perl expert. The runtime error is: Bad file descriptor at io.pl line 19. Your code works for me, so maybe you need to or die Fudge() to get more info, maybe Also, you don't need to fdopen , all you need is `select OUTPUT;` Speaking of which, that style of subs that print to default handle is kinda smelly :)	[reply]
Re^2: unusual behaviour with Inline-Files and IO-Handle (select) by Peamasii (Sexton) on Dec 07, 2015 at 16:17 UTC
Thanks for your suggestions, when changing fdopen to a select(OUTPUT) statement, I get a new Inline section at the end of the script: `__OUTPUT__ headerprint` [download] so I think Inline::Files is acting really weird, instead of writiing to an external file, it writes to a new data section in my script.	[reply] [d/l]
Re^3: unusual behaviour with Inline-Files and IO-Handle (select) by kcott (Archbishop) on Dec 07, 2015 at 19:02 UTC
"so I think Inline::Files is acting really weird, instead of writiing to an external file, it writes to a new data section in my script." Far from being "really weird", that's actually documented behaviour. It even alerts you to this behaviour in the WARNING section which has two paragraphs: "It is possible that this module may overwrite the source code ..." "This module is still experimental. ..." I have used Inline::Files for demonstration purposes only (particularly on this site) to save having to create and list multiple input files as well as the source code of my script. I have never used this module in production and, given its experimental status, never intend to. If you are using this module in production code, I'd strongly recommend finding an alternative, non-experimental solution. — Ken	[reply]