Re^2: First attempt at bringing in file for input/output

[talexb]

Although operator precedence will do the right thing in your code ..

open my $FH_infile,  '<', "$in_file"  or die "Can't open $in_file";
open my $FH_outfile, '>', "$out_file" or die "Can't open $out_file";

I prefer the more explicit

open ( my $FH_infile,  '<', "$in_file" ) or
  die "Can't open $in_file";
open ( my $FH_outfile, '>', "$out_file" ) or
  die "Can't open $out_file";

In addition, I do like to give myself as much information as possible by adding $! to error messages:

open ( my $FH_infile,  '<', "$in_file" ) or
  die "Can't open $in_file: $!";
open ( my $FH_outfile, '>', "$out_file" ) or
  die "Can't open $out_file: $!";

Also, I wasn't aware of File::Basename .. that's pretty handy.

[Your Mother]

FWIW, I recommend Path::Tiny over File::Basename. It does much more.

[Marshall]

Don't know why I didn't have $! in the die message. Good catch..including that is a good idea and I do it except when I make a mistake like above!

While we are talking about die messages, another option that I sometimes use is to suppress the Perl module name and source code line number from the error message. That is done by simply adding a \n to the message, e.g.  die "Can't open $out_file: $!\n"; This choice has to do with who I'm writing the code for. For other programmers, sys admin types, I leave everything in there. Sometimes I write pre-complied .exe's for very inexperienced computer users and in that case, I've found that the extraneous information doesn't help them because they don't understand it and they don't have the source code anyway. I rarely do this, but rare doesn't mean "never".