in reply to Putting file contents into a scalar

You're nearly there, but should specify the file-handle as a 'bareword', like FILE instead of $FILE.

This will do the trick: 

my $contents;
{
  local $/;
  open (FILE, $txt_file) || die "Cannot open $txt_file:$!";
  $contents = <FILE>
}

[download]
Update: You would likely have been warned if you used strict (because $FILE was uninitialised).
As a sidenote: there is a nice idiom to slurp in a file in thread Cheap idioms.

--
Cheers, Joe

Replies are listed 'Best First'.
Re^2: (nrd) Putting file contents into a scalar
by newrisedesigns (Curate) on Oct 29, 2002 at 12:51 UTC

    You can specify a filehandle as:

    my $fh;

    The root nodes problem is that he/she tried FILE and then $FILE, which does not work.

    *FILE != $FILE

    I prefer to use the $ convention, as opposed to the bareword. I think it keeps my code cleaner, as I don't feel the need to double-check for any other "barewords" that might not be what I was expecting.

    Just my two cents...

    John J Reiser
    newrisedesigns.com

[reply]
[d/l]
[select]
      For my own code, I even prefer to use IO::File because that gives me all that neat OO stuff on the file handle. And the additional benefit to be able to test for the type of a scalar which happens to be passed to me, by checking for ref $fh eq 'IO::File'.

      But that's much typing for oneliners...

      Update: As merlyn correctly pointed out:

      "Please don't do that. Your code is fragile. It will break when I pass an object that subclasses IO::File but acts in every way like an IO::File".
      So I went through my latest and greatest module, which grossly offends against this statement, and quietly changed my test to read: 
      ...
croak("Invalid type for 'outfile', missing method print()'")
  unless $outfile->can('print');
...

      [download]
      The immediate benefit is that I now can use IO::Scalar from my test script to get output in a variable instead of a file (or STDOUT). Cool!

      --
      Cheers, Joe

[reply]
[d/l]
[select]
        And the additional benefit to be able to test for the type of a scalar which happens to be passed to me, by checking for ref $fh eq 'IO::File'.
        Please don't do that. Your code is fragile. It will break when I pass an object that subclasses IO::File but acts in every way like an IO::File.

        Instead, write your code so that the class doesn't matter. Use the polymorphism as it was intended. If you are unsure if $object_x can handle a particular method call, then use UNIVERSAL::can against it, or put it in an eval block to trap the potential error.

        The use of ref in ordinary code should be limited to determining whether something is a reference or not (such as whether the first parameter for a method call is a class or instance). Any explicit comparison will break subclassing. Too much "navel contemplation" is a bad thing in robust code.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]

In Section Seekers of Perl Wisdom