while(<NODE>){
    push(@lines, $_);
}
[download]

push( @lines, <NODE> );
[download]

if($is_script eq 'yes'){
      middle();
      bottom();
  } else {
      top();
      middle();
      bottom();
  }
[download]

top() unless ($is_script eq "yes");
middle();
bottom();
[download]

xoxo,
Andy

%_=split/;/,".;;n;u;e;ot;t;her;c; ".   #   Andy Lester
'Perl ;@; a;a;j;m;er;y;t;p;n;d;s;o;'.  #   http://petdance.com
"hack";print map delete$_{$_},split//,q<   andy@petdance.com   >

1. As petdance pointed out, your file reading routine can be simplified:

        @lines = <NODE>; </CODE>

2. Further, you can directly insert into a hash from your split, because in a sense a hash is just a fancy list:

        %known_files = map { my($k,$v)=split(/=/) } <LINKS>;

3. Post-processing would allow you to figure out the 'top_level' stuff:

        foreach (keys %known_files)
        {
             if(/announcements|links|news|info/i)
             {
                   $top_level{$_} = $known_files{$_};
             }
        }
   [download]

4. When you want to print an array, you just print it. You don't need to do anything special.

        sub middle
        {
             print @lines;
        }
   [download]

I don't like code that updates a global value when it's not necessary. I like to be able to see, easily, where information comes from. This results in more maintainable code (you know where to look when something goes wrong).

That said, I'd rewrite your populate_hash to return a hash, or better still (for performance reasons), a reference to a hash. You then set %top_level to the return value of that subroutine. It's as easy as having the first line of the sub be:

sub populate_hash {
    my %hash;
    # populate hash
    \%hash;
}
[download]

Note this returns a reference to a hash, which means you have to get a little fancier when you call the subroutine (or modify your code to work with the hash reference, but I foresee less hair-pulling if you keep the hash).

my %top_level = % { populate_hash() };
[download]

The "extra" %{} parts tell the interpreter that it should set %top_level to the hash which the return value of populate_hash refers to.

I swear that makes sense in some language. =) For more on references, see perldoc perlref and perldoc perlreftut. Once you get the hang of working in references, you see all sorts of new solutions to data-manglement.

HTH

perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); 
+$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth
+er_name\n"'
[download]

#do the output
  if($is_script eq 'yes'){
      middle();
      bottom();
  } else {
      top();
      middle();
      bottom();
  }
[download]

top() unless $is_script eq 'yes';
middle();
bottom();
[download]

Update: petdance said the same thing explaining it. I didn't noticed his reply (probably he submitted it while I was preparing this one)

You could also consider taking a look at Template as I'm doing in these days. It seems interesting since it lets you separate the logic from the presentation. But this topic has been already discussed in the monastery (Web Application Frameworks and their Templating Engines with a Comparative Study of Template and HTML::Template).

Your program works with two files for each run, one is the index and the other is the content. Under mod_perl the index, at least, should be held in RAM and you will be down to one file read per page. If you have enough RAM you should consider keeping both files in RAM. You could have a hash $file_content{$node} that stores a file per node as each file is read. This way the daemon would only read each file once.

To further speed up your code, eliminate as many print statements as possible. For example, change:

        print $q->header('text/html');
        print $q->start_html(-title=>$node,
                               -author=>'schmidtd@co.delaware.pa.us',
                               -BGCOLOR=>'white');
[download]

to

       
        print $q->header('text/html'),
              $q->start_html(-title=>$node,
                             -author=>'schmidtd@co.delaware.pa.us',
                             -BGCOLOR=>'white');
[download]

This uses ',' to separate the arguments to print, rather that a '.' since the comma is faster than string concatenation.

The code goes to the trouble of reading the file into an array, and then printing it out one array element at a time. You don't need to do this. Instead, read the whole file into a single string and print the string.

If you don't want to follow my advice on not using an array, at least change

    
foreach(@lines){
           print $_;
}
[download]

 
my $content;   
foreach(@lines){
  $content .= $_;
}
print $content;
[download]

print join "\n",@lines;
[download]

There are some other speedup tips at a previous node that I wrote on this topic.

It should work perfectly the first time! - toma

my $links = 'h:\perl scripts\links.txt';
[download]

Since this is apparently a constant, you might consider rewriting it as:

my $LINKS = 'h:\perl scripts\links.txt';
[download]

But if you want to be rigorous and good about preparing for when your script needs to do everything and run the kitchen sink, you might go so far as to write:

sub LINKS { return 'h:\perl scripts\links.txt'; }
[download]

While your program remains simple , I believe that this will be inlined by the Perl compiler (so no performance hit), but if your program grows, such that lines might change depending on the context, you only have to rewrite the subroutine and everything else will work as expected.

Actually, looking at your middle sub, I can't see any reason why you wouldn't just suck the file into a scalar and save yourself the overhead of array allocation:

undef $/;
[download]

To make things more reader-friendly and more extensible it's also a good idea to pass variables to your subs rather than simply calling variables declared elsewhere:

sub middle {
    my @output = @_;
    print while @output;
}
[download]

This sub now only makes the assumption that it should print whatever you've passed it... so now, it's re-usable and should probably be renamed print_to_user or some such.

DISCLAIMER: I've been stuck as a Java programmer for the past few months so my Perl's getting more than a little rusty (trying to get involved again in Perlmonks), so not all of this stuff may perform as advertised. If so, then I apologize.

Instead of

sub LINKS { return 'h:\perl scripts\links.txt'; }
[download]

you're better off to be more Perlish with constant.pm:

use constant LINKS => 'h:\perl scripts\links.txt';
[download]

xoxo,
Andy

%_=split/;/,".;;n;u;e;ot;t;her;c; ".   #   Andy Lester
'Perl ;@; a;a;j;m;er;y;t;p;n;d;s;o;'.  #   http://petdance.com
"hack";print map delete$_{$_},split//,q<   andy@petdance.com   >

Yes, but consider a change needing to be made down the line:

Q: "Hey petdance we're porting this script to Unix, can you make it run there too?"

A: "Sure, I'll just change the constant."

Q: "Hey what did you change in that script so that now it doesn't work on NT anymore?"

A: "Hmmmmm"

Ok, so the example is a stretch, but imagine the solution using a sub instead of a constant.

sub LINKS {
    if (sub_to_determine_OS() =~ /(Unix|Linux)/) {
        return "/u/jreades/links.txt";
    } else {
        return "U:\jreades\nt_links.txt";
    }
}
[download]

And all of that requires exactly no changes to the rest of your application.

Yes, it is paranoid, but that doesn't mean they're not out to get you.

I generally like to pass in locations with either environment variables or thru command line options. Saves on going back through all your code when the directory structure changes... Although some may disagree with me :)

As far as the http header thing, the idea is that if it is a script file, it reads all of it in, which would include the http header. the regular files would be coded to start and end at the body tags.