Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Common Perl Pitfalls

by JavaFan (Canon)
on Apr 09, 2012 at 23:11 UTC ( [id://964222]=note: print w/replies, xml ) Need Help??


in reply to Common Perl Pitfalls

The solution: redefine $/ right after your slurp:
No. That's just another potential problem. The solution is:
my $slurp; {local $/; $slurp = <INPUTFILE>};
Or:
my $slurp = do {local(@ARGV, $/) = "inputfile"; <>};
Or even:
my $slurp = `cat inputfile`;

Replies are listed 'Best First'.
Re^2: Common Perl Pitfalls
by Joe_ (Beadle) on Apr 09, 2012 at 23:14 UTC

    Great stuff. Thanks for the feedback.
    I really like the second solution.
    The third solution isn't as portable, though.
    Why do you think redefining $/ as I did is a potential problem?

      The third solution isn't as portable, though.
      cat is probably available on more platforms than perl is. Of course, Windows rules the world, and both cat and perl are ported to Windows -- and, AFAIK, neither comes standard with the OS. Unlike cat, perl is not included in the POSIX standard for shell utilities.

      Why do you think redefining $/ as I did is a potential problem?
      Well, you consider someone modifying the code to be a potential problem. Would if someone modifies your code, and adds a return after the first assignment to $/, but before the second? Would if someone wraps the code in an eval, and the read triggers an exception?

        Well, that's a tad too advanced for me at the moment. But thanks for sharing your insight. And I had no idea that cat was ported to Windows. I was never what you can call a Windows power user. Thankfully, I switched to Linux :)

Re^2: Common Perl Pitfalls
by chrestomanci (Priest) on Apr 11, 2012 at 12:59 UTC

    Rather than mess around with $INPUT_RECORD_SEPARATOR (AKA: $/), and restore it afterwards, a better method would be to use the File::Slurp module.

    It is another common Perl pitfall to write new code for a common problem when you should have looked on CPAN. There is a very good chance that you will find a fully debugged implementation that considers all the edge cases. It never ceases to amaze me that people would prefer to spend half a day writing and debugging code, instead of 15 minutes finding and installing a module from CPAN.

      It always amazes me people prefer downloading a CPAN module, and using it, over writing a one-liner. I'm even more amazed that people think that just because there's a module on CPAN, it automatically is fully debugged and covers all the edge cases.

      I do wonder though, if it takes half a day to write:

      my $slurp = do {local $/; <HANDLE>};
      how long do you need to type in:
      use Some::Module::From::CPAN; my $slurp = Some::Module::From::CPAN->some_API(some_argument);
      Twice the number of lines, so, a full work day?
        use File::Slurp; my $text = read_file( 'filename' );

        Yeah, that's a whole day's work.
        I submit that finding the documentation on such a method is substantially easier than finding the documentation (for lack of a better word) for the snippet you gave.

        Note.
        The "cost" of useing the module is amortized over all the calls you make to any of its methods (of which File::Slurp has several useful ones).

        And the cost of downloading a module is amortized over all of the times you ever use it (at least on that machine).

Re^2: Common Perl Pitfalls
by dwalin (Monk) on Apr 10, 2012 at 23:20 UTC
    First solution is not equal to last two, as it implies that INPUTFILE is already open. I would say that the correct idiom looks like this:
    my $slurp = do { open my $fh, '<', "inputfile"; local $/; <$fh> };

    P.S. I really like the second one, thanks. Not for production use, of course. :)

    Regards,
    Alex.

      Considering that Joe_'s example uses the handle INPUTFILE, I don't have any problems with the implication, and I really don't see the need to come up with the snobby term correct idiom. (You consider a piece of code with error handling to be correct idiom? You're fired).
      I really like the second one, thanks. Not for production use, of course. :)
      Why not? It's not significant different from your correct idiom. It misses error handling (but then, so does your correct idiom), but that's easily handled: just add a // die "slurp: $!";.

        Considering that Joe_'s example uses a handle and your last two use filename, it could be confusing for a novice.

        Why I wouldn't use the second example in production? Readability. Not everybody is familiar with intimate relationship between @ARGV and <>, and this solution doesn't really give any advantage over the common one.

        P.S. As for your show-off harshness, I care less for anti-snobs than I do for snobs. You didn't hire me, you have no authority to fire me. Have a good day sir.

        Regards,
        Alex.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://964222]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2024-03-28 08:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found