Re: Newby question

#!/usr/bin/perl -w
use strict;

#This program asks for an input file, output file, a string, 
# and a replacement string.  It then searches the input file 
# for the string and substitutes it with a phrase of the
# user's choice.

#get user input...
#there are many problems with this code...

#Open the file, perform the substitutions, and create the 
#   new user named file.
open (READFILE, "$infile") 
        || die "Can not open input file $infile: $!" ;
open (WRITEFILE, ">$outfile") 
        || die "Can not create outfile $outfile: $!;
while (<$infile>) {  ### PROBLEM ###
                     ### Should use READFILE, the file handle ###
                     ### instead of the string "$infile" ###
                     ### while (<READFILE>) ###
    print WRITEFILE "$_" ;
}
[download]

The $! variable can be useful, but it is often not.
This is basically the OS error code text. That does not normally contain the file name that that was "under question".
If want to "die" or "warn", then I would echo the file name that didn't work.

Comment on Re: Newby question Download Code

Replies are listed 'Best First'.
Re^2: Newby question by Parmenides (Novice) on Aug 08, 2012 at 04:56 UTC
That sounds useful. How do I do that?	[reply]
Re^3: Newby question by Marshall (Canon) on Aug 10, 2012 at 10:30 UTC
Below are some examples of "die" messages on my Windows machine for a non-existent file. I used "warn" instead of "die" so that all 4 examples would run. In the first example, I just have the OS error code $!. Well if the code is opening many files, "which file?" is not known - although you can get the Perl source line that the error occurred on. I don't expect users to have to look into the code so that isn't ideal. The second example, I put the filename that was trying to be opened into the "die" message. That is often way more useful than the OS error code alone. Usually not to hard to figure out why that file couldn't be opened. In the third example, I put both the filename and error code. I most often include both pieces of information. Also note that I also put whether a read, write or append was attempted into the error message. In the fourth example, I suppress the output of the Perl source line number by simply appending a "\n" to the "die" string. In a lot of situations, the user doesn't care about this Perl code line and it just clutters things up and can confuse folks. #!/usr/bin/perl -w use strict; my $infile = 'bogus_name'; open IN, '<', $infile or warn "$!"; # No such file or directory at C:\TEMP\demoOpenMessage.pl line 6. open IN, '<', $infile or warn "cannot open $infile for reading"; #cannot open bogus_name for reading # at C:\TEMP\demoOpenMessage.pl line 6. open IN, '<', $infile or warn "cannot open $infile for read-> $!"; #cannot open bogus_name for read-> No such file # or directory at C:\TEMP\demoOpenMessage.pl line 12. open IN, '<', $infile or warn "cannot open $infile for read-> $!\n"; #cannot open bogus_name for read-> No such file or directory [download]	[reply] [d/l]