[Purdue-pm] help!

MCNAMARA, KEN km1921 at att.com
Wed May 16 10:53:31 PDT 2012

The sub routine returns the ‘last evaluated expression’.

If you wrote (in the body of the subroutine):

my $value;
while(<FH>) { $value = $_; }
return $value;

Then you get the contents of the file as intended.

my $next = <FH>;  -- is meaningless since FH was already at end of file in “while(<FH>)”.


From: purdue-pm-bounces+km1921=att.com at pm.org [mailto:purdue-pm-bounces+km1921=att.com at pm.org] On Behalf Of Bradley Andersen
Sent: Wednesday, May 16, 2012 1:49 PM
To: Joe Kline
Cc: mark at purdue.edu; Purdue Perl Mongers
Subject: Re: [Purdue-pm] help!

I have just confirmed using the latter (new) method that the first <FH> does not do what I had thought (skip first line of the file read).

So Joe's comment about trying to be too clever on that bit looks correct.

On Wed, May 16, 2012 at 1:27 PM, Bradley Andersen <bradley.d.andersen at gmail.com<mailto:bradley.d.andersen at gmail.com>> wrote:
Yeah, in the end I don't care if it is clever or not, so long as the code works and it is readable :)

On Wed, May 16, 2012 at 1:25 PM, Joe Kline <gizmo at purdue.edu<mailto:gizmo at purdue.edu>> wrote:
Hash: SHA1

On 05/16/2012 01:20 PM, Bradley Andersen wrote:
> ok, i just fixed it, but i'd like to still figure out why it worked
> then stopped.  there must be something wrong with the earlier
> logic.  for reference, here's what i did:
> i replaced: 1999             #####open(FH,
> "$base/helping$full.html") || die "\n\nCould not READ
> $base/helping$full.html: [$!]\n\n"; 2000
> #####$tpl->param("m$full" => do { local $/; while (<FH>) { my $next
> = <FH>; } });
> with: 2001 2002             my $contents; 2003             { 2004
> local $/; 2005                 open(FH, "$base/helping$full.html")
> || die "\n\nCould not READ $base/helping$full.html: [$!]\n\n"; 2006
> $contents = <FH>; 2007                 close(FH); 2008
> } 2009             $tpl->param("m$full" => $contents);
> Can you see immediately why the first one would be no good? It
> almost seems like the tpl->param is not being set as a string.
> That is, clearly it reads it, but it is not assigning the result
> properly as a string.  All I got were undefs in the log for the
> earlier logic.  I am 199% sure this worked using the earlier logic
> yesterday.

I don't see much of a reason why the file slurping wasn't
working...maybe that bit to strip the first line out was a bit too much?

It took me a bit to figure out why that slurp line looked familiar but


I guess just an example where the less clever option worked out better.

Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

Purdue-pm mailing list
Purdue-pm at pm.org<mailto:Purdue-pm at pm.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/purdue-pm/attachments/20120516/15912e36/attachment.html>

More information about the Purdue-pm mailing list