in reply to Issue splitting in while Loop

To add a little emphasis to AnomalousMonk's sage advice: always use strictures (use strict; use warnings; - see The strictures, according to Seuss).

In addition always use three parameter open, lexical file handles and report open errors. Consider:

open my $ranIn, '<', $logFileName or die "Open '$logFileName' failed: 
+$!\n";

[download]

There are at least three important points here. Using a lexical file handle ($ranIn in the sample) reduces the likely hood of a typo in the file handle name resulting in strange and hard to debug runtime errors. Using the quotes around the file name in the die helps see unexpected white space and newlines (commonly from unchomped input data). And the explicit open mode helps avoid errors such as opening a file for input (the default) then trying to write to it, or executing arbitrary user supplied command lines when the file name is supplied at run time.

True laziness is hard work

Replies are listed 'Best First'.
Re^2: Issue splitting in while Loop
by koolgirl (Hermit) on Jul 30, 2011 at 03:27 UTC

    Nice input GrandFather, however, I'm a little perplexed about your example ..

    open my $ranIn, '<', $logFileName or die "Open '$logFileName' failed: $!\n";..

    Where is the filehandle that's being created, is that in a variable ($ranIn) as well as the file name ($logfilename)? The syntax is a bit off as to what I'm used to, but that part I'm figuring out, for instance my open statement would look like this...

    open (IN, "$logfilename") || die "Open '$logfilename' failed: $!\n";

    So, I'm thinking the only real difference is that you've got the filehandle, IN, in $ranIn, and you're explicitly using "<" to mean input file rather than rely on default, am I correct about that, and if so, what are the benefits of opening the file this way?

    By the way, I know you explained some of why you did it this way in the post, but I'm just not really understanding exactly what your reasons are, sorry, not too quick on the uptake some times...:)

[reply]
[d/l]
[select]

      This is an issue that comes up a lot. Perl inherits a lot of syntax and style from C and various other languages so some of the conventions used in older Perl derive from what was required in other languages. However Perl has moved on and there are now often clearer and safer ways of doing things. As mentioned in my previous reply there are several issues related to using old school two parameter open and bare word style file handle identifiers (IN in your example). There are two main issues with using bare word file handles: it is easy to mistype them and introduce subtle and hard to find bugs, and bare word file handles have global scope.

      The typo issue should be fairly obvious. The global scope thing is less so and understanding depends on understanding the difference between package variables and lexical variables. Lexical variables are the ones you introduce using my and they are pretty much limited to the block they are introduced in. For a file handle that means that the file is closed for you when processing exits the block containing the lexical variable. Consider:

      for my $fileIdx (1 .. 10) {
    my $logName = "log$fileIdx.txt";

    open my $logOut, '>', $logName  or die "Can't create $logName: $!\
+n";
    ...
}

      [download]

      which creates 10 log files. Notice that a close isn't needed because $logOut goes out of scope at the closing } and Perl closes the file for you.

      The three parameter open issue is also two fold. The first thing is that two parameter open defaults to input so it is fairly easy to forget that you need to provide the > to specify output - somehow that is a really hard bug to spot! The second, and more subtle issue is that a user supplied file name can run a command supplied by the user by appending a pipe ('|') character to the command and presenting that as the file name.

      Note by the way that the file name is not the file handle. open creates a file handle using the file name and mode information. The file handle is just the way the functions which deal with the file for I/O know which file to manipulate and what operations are OK.

      True laziness is hard work
[reply]
[d/l]

In Section Seekers of Perl Wisdom