open Best Practices

++ For making this :)

Unless you are using autodie, I'd say: always use a temporary variable for the filename, to use both in the call to open and in the error message. This is to avoid having an error message that says that file A is missing, or can't be read, when you were actually trying to read file B, and to avoid looking in the wrong folder. Two examples (which I've both been guilty of):

open my $input, '<', "my_input.xml" or die "Can't open my_input.csv: $
+!"; # Whoops, my_input.xml does not exist by my_input.csv file does

my $input_file = "my_input.xml";
open my $input, '<', $input_file or die "Can't open $input_file: $!"; 
+# Still doesn't work but the error message is correct
[download]

my $file = get_file(); 
my $folder = get_folder(); # The function returned an empty string by 
+mistake
open my $data, '<', "$folder/$file" or die "Can't open $file; $!"; # B
+ut I see the file my folder, why does it say it doesn't exist?

my $input_file = "$folder/$input";
open my $data, '<', $input_file or die "Can't open $input_file: $!"; #
+ You'll see straightaway that you the folder is empty
[download]

Also, that's not really specific to open but try to give meaningful names to your variables. Having to use numbers is nearly always a sign that the name is wrong. $input and $output is always better than $file and $file2. $reference_data and $new_data is also better than $fh1 and $fh2.

Perhaps mention something about paying attention to the ownership and permissions on newly created paths and files, and to consider the ramifications of locking (or failing to do so). So often we envision our solutions in terms of simple development environments not considering that there's a real world where processes can compete with each other over the same resource, or where not everyone is the same person as $ENV{'USER'}, and so on. At minimum, if our code is expected to be the only instance of itself running (so that it's not competing for a resource with other instances of itself) are we doing anything to assure it is the only instance? Have we considered that someone might be writing to, unlinking, moving, copying, reading from the same file we're working with?

Using open correctly is the easy part.

Yes, making the code robust in the face of (perhaps rare) environmental conditions, such as a power failure or the user pressing CTRL-C while the program is running can be surprisingly tricky to get right. Two examples I remember are:

• Perl Best Practices book: is this one a best practice or a dodgy practice?
• Re: Lock File

Using open correctly is the easy part.

Yes, and hence my relatively short node - I really just wanted to focus on the open statement itself, so I'd have something to link to in posts like this one. But I've added a mention of your suggestion to the root node, thanks!

"...the easy part."

Well said. Some callow thoughts about some situations when things get a little bit harder: I just wondered if some ugly locking stuff could be handled with mce_open from MCE::Shared::Handle. Probably this may be yet another case of total abuse of a module. And testing with lsof if a file is in use might be an option from time to time as well. Best regards, Karl

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Hi karlgoethebier,

The mce_open call behaves similarly to the native open in Perl. It creates a shared handle with exclusive locking handled transparently.

Example:

use strict;
use warnings;
use feature 'say';

use MCE::Hobo;
use MCE::Shared;

# Passing a file ref without IO::FDPass will work for \*STDIN,
# \*STDOUT, \*STDERR, and \*main::DATA only. Otherwise, providing
# the actual path is preferred (i.e. "/path/to/file").

mce_open my $out, '>>', \*STDOUT or die 'open failed: $!';
mce_open my $err, '>>', \*STDERR or die 'open failed: $!';

printf $out "shared fileno(\$out) is %d\n", fileno($out);
printf $out "shared fileno(\$err) is %d\n", fileno($err);

if ($^O ne 'MSWin32') {
    mce_open my $log, '>>', '/dev/null' or die 'open failed: $!';
    say $log "Hello, there!"; # sent to null
}

# The shared-handles work with threads, MCE::Hobo, MCE::Child,
# Parallel::ForkManager, and other parallel modules on CPAN.
# Note: There is no reason to choose MCE::Child over MCE::Hobo
# if already involving the shared-manager.

sub foo {
    my ($id) = @_;
    say $out "Hello, from pid $$";
}

MCE::Hobo->create('foo', $_) for 1..4;
MCE::Hobo->wait_all;
[download]

Output:

shared fileno($out) is 1
shared fileno($err) is 2
Hello, from pid 4651
Hello, from pid 4652
Hello, from pid 4653
Hello, from pid 4654
[download]

See also:

https://metacpan.org/pod/MCE::Shared#DBM-SHARING
https://metacpan.org/pod/MCE::Shared#LOGGER-DEMONSTRATION

Regards, Mario

> It is best to also report the filename as well, and of course you're free to customize the message as needed.

About this I almost always use the filename within square brackets or single quotes, to avoid nasty empty space problems (even if your use, with filename as first element and followed by : can spot these problems too). I also spend more words in errors, just in case:

open my $fh, '<', $filename  or die "Unable to open [$filename] becaus
+e of: $!";
[download]

Also, being on unfortunate OS , sometimes I add $^E aka $EXTENDED_OS_ERROR ( under MSWIN32 $^E can be different from $! ):

open my $fh, '<', $filename  or die "Unable to open [$filename] becaus
+e of: $! $^E";
[download]

L*

G'day haukex,

++ Good write up and definitely handy for linking: I've certainly written similar information in dozens of replies over the years.

"use autodie qw/open/;  # at the top of your code"

Possibly out of scope for this; but, it may be worth mentioning the lexical nature of autodie.

I've worked on a lot of production code that uses in-house I/O error handling; e.g. the custom handling includes logging, email alerts, popup messages, and so on. At times, I don't want this for a small part of code I've added; however, I also don't want to interfere with the existing, custom error handling.

A very rough example might be something like:

...
use InHouse::IO::ErrorHandling;
...
open ...; # in-house handling here
...
{
    use autodie;
    ...
    open ...; # autodie handling here
    ...
}
...
open ...; # in-house handling here
...
[download]

Nice! I'd add a blurb about using close(), as well as a scoped block example (perhaps linking the two). One good example of when to use a block is using a local record separator variable (the close isn't really necessary in this case, but I digress):

my $file = 'test.txt';
my $json;

{
    local $/;
    open my $fh, '<', $file or die $!;
    $json = <$fh>;
    close $fh;
}
[download]

Thanks, and yes, good points! The node is aimed at people using the open statement in a "non-best-practice" way, so I'd like to keep the node short enough so that they might still read it (hence all the bold text and TL;DR at the top), and I'd like to keep the focus on the open statement itself - I left out a discussion e.g. of piped opens and checking close for errors and such intentionally, because when answering questions about that, I have other nodes I'd link to instead. Perhaps your reply to my node pointing these things out is enough? :-)

Update: Ok, I've updated the root node!

Thanks for the write-up, it's very useful. The first para can be read to imply that the not-so-good options are currently best practices.

You will see styles of open such as "open FILE, $filename;" or "open(LOG, ">$filename") || die "Could not open $filename";" in many places. These mainly come from versions of Perl before 5.6.0 (released in 2000), because that version of Perl introduced lexical filehandles and the three-argument open. Since then, they have become a best practice, for the reasons below.

Perhaps reword "they have become best practice" to something like "the three argument open has become a best practice".

I thought about how to make it more clear without repeating myself too much, so I hope I've improved the wording now. Thank you for pointing this out!

Thank you! Can't say I've always done that in the past (although I've been using the 3-arg form for..?ever?). The "or die" with $!:

open my $fh, '<', $file
  or die "$0: cannot open $file: $!";
[download]

has been updated in my quick snippets!

UPDATE: removed extra semicolon after first line - thanks haukex

Nice writeup, indeed good for linking to.

Some minor nitpickings:

• I like to enclose both the file name and the error messages in quotes, to separate them clearly from your own message text. Especially error messages usually have several words, which sometimes makes parsing of the sentence difficult.
• I would also include the operation (read, write) which was desired.

By the way: autodie does all of that :)

Nope, its never "OK", to write code like that is to never get work :)

:)
Common Perl Pitfalls
perltrap
"or die" versus "|| die"
To || or not to or and why.
Perl Idioms Explained - && and || "Short Circuit" operators
Re: Undefined vs empty string (not length)

Well, I disagree with the "never", but I did strengthen my warning against it a bit, thanks! BTW, some of those links are of course very relevant, but some of them (e.g. the first two) don't mention the || vs or at all.

I always use the low precedence and and or operators for flow of control, for example preferring:

open(my $fh, '<', $file) or die "error opening '$file': $!";
[download]

to the equivalent:

open(my $fh, '<', $file) || die "error opening '$file': $!";
[download]

while always using && and || inside logical expressions, for example preferring:

if ($x > 5 || $y < 10) ...
[download]

to the equivalent:

if ($x > 5 or $y < 10) ...
[download]

When this style is followed consistently, I find the code easier to read and understand at a glance.

See also Perl Best Practices, Chapter 4, "Values and Expressions", "Don't mix high- and low-precedence booleans" item.