add new old article

Author: szabgab

open-files-in-the-old-way.tt

@@ -0,0 +1,137 @@
+=title Don't Open Files in the old way
+=timestamp 2013-03-21T08:45:17
+=indexes open
+=status show
+=books beginner_book
+=author szabgab
+=index 1
+=archive 1
+=feed 1
+=comments 1
+=social 1
+
+=abstract start
+
+Earlier in the <a href="/perl-tutorial">Perl Tutorial</a>
+we saw how to open a file for reading or writing.
+Unfortunately, when you search the web, or when you look at code
+in corporations you will see some slightly different syntax.
+
+Let's see what is that, what is the problem with that and why to avoid?
+
+=abstract end
+
+<h2>So what shall I do?</h2>
+
+Before explaining what you should not do, let me link you to the articles explain what you should do:
+
+Read <a href="/open-and-read-from-files">how to open file for reading in a modern way</a>
+or the one about <a href="/writing-to-files-with-perl">writing to file in Perl</a>.
+
+Now let's get back to the old, and not-so-good-any-more practices.
+
+<h2>The old and not recommended way</h2>
+
+Until perl 5.6 came out - that's until 2000 - we used to write code
+like this to open a file for writing:
+
+<code lang="perl">
+open OUT, ">$filename" or die ...;
+</code>
+
+and code like this for reading:
+
+<code lang="perl">
+open IN, $filename or die ...;
+</code>
+
+The "or die" part was the same as we do today, not fully spelled out here.
+
+As you can see <hl>open</hl> got two parameters. The first is a set
+of (usually upper-case) letters. That's the thing that will get the
+filehandle. The second is the combined opening mode and the path to
+the file that needs to be opened.
+
+That is, in the first case you see the greater-than sign meaning we
+are opening the file for writing, but in the second example we used to
+omit the opening mode. That's because <hl>open()</hl> defaults to reading.
+
+There are two big differences:
+
+<h2>Filehandle glob</h2>
+
+The first is that we use the strange variable without the
+leading <hl>$</hl> to hold the filehandle.
+(This is actually a <b>bareword</b>, but one that does not trigger
+the <a href="/barewords-in-perl">Bareword not allowed while "strict subs" in use</a>
+error.)
+
+It works as it worked in the early days of Perl, but there are several problems with it:
+
+It is global to all the script you write so if anyone
+uses the same name (IN or OUT in our example) those
+will clash with yours.
+
+It is also harder to pass these variables to functions,
+than to do the same with regular scalar variables.
+
+<h2>2 parameter open</h2>
+
+The second difference is the fact that in these examples <hl>open</hl> got only two parameters.
+
+What if the variable <hl>$filename</hl>, that you are using to open
+a file for reading, contains >/etc/passwd ?
+
+Oups.
+
+The <hl>open IN, $filename</hl> will actually open that file for writing.
+
+You just deleted the password file of your Linux operating system.
+
+Not good.
+
+<h2>Need to close that filehandle</h2>
+
+Another advantage of using <b>lexically scoped scalar variables</b>
+as filehandles is that they will automatically be closed when
+they go out of scope.
+
+<h2>How to avoid these problems?</h2>
+
+It's better to avoid both of these practices and use the "new",
+(available since 2000 !) <a href="/open-and-read-from-files">3-parameter open
+with scalar lexical variable</a> for storing the filehandle.
+
+There are even policies in <a href="http://www.perlcritic.com/">Perl::Critic</a>
+that will help you analyze the code and locate every place where someone has used either
+of the above forms.
+
+<h2>Good and Bad for reading</h2>
+
+Bad:
+
+<code lang="perl">
+open IN, $filename or die ...;
+</code>
+
+Good:
+
+<code lang="perl">
+open my $in, '<', $filename or die ...;
+</code>
+
+<h2>Good and Bad for writing</h2>
+
+Bad:
+
+<code lang="perl">
+open IN, ">$filename" or die ...;
+</code>
+
+Good:
+
+<code lang="perl">
+open my $in, '>', $filename or die ...;
+</code>
+
+