It looks like the read pointer was going to the beginning of the file on 
Solaris, but the end of the file on Linux.  I've edited the script to do 
separate opens for when I need to read the file and when I need to append to 
it.  I'm running the script now to check for any unintended consequences.  

My take-away on this, is to avoid the use of "+>>" to open a file.  In fact, in 
doing further research I saw that exact advice in the Perl Cookbook, and for 
just this reason.

Thanks to Brad Baxter for (pardon the pun) pointing me in the right direction.

-- Michael

> -----Original Message-----
> From: Doran, Michael D [mailto:do...@uta.edu]
> Sent: Saturday, March 17, 2012 2:09 PM
> To: perl4lib
> Subject: File open head scratcher
> 
> I am migrating  a perl script from a server running perl v5.8.5 on Solaris
> 9 to a server running perl v5.12.2 on Redhat Linux 5.5.  The new
> environment doesn't seem to like the syntax I'm using to open a file, and
> I'm scratching my head over why that is the case.
> 
> That part that is not working appears to be where it opens and reads a
> file (a file which it will later append to).  The file that is being
> opened for read and appending exists and contains data.
> 
> This appears to be the relevant code:
> 
>   open (my $DATEFILE, "+>>$date_file")
>         || die "Cannot open $date_file: $!";
> 
>   my @run_dates = <$DATEFILE>;
> 
> 
> Any idea why this wouldn't work?
> 
> Below is a test script I'm using to isolate the behavior.  I'm using a
> system call to cat the contents of the file out, then after opening the
> file, using perl to print out the contents.
> 
> #!/m1/shared/bin/perl
> 
> use strict;
> use warnings;
> 
> my $date_file  = "/m1/incoming/ab/dates.txt";
> 
> system qq(cat $date_file);
> 
> print "\n\n **** cat done ****\n\n";
> 
> open (my $DATEFILE, "+>>$date_file")
>         || die "Cannot open $date_file: $!";
> 
> my @run_dates = <$DATEFILE>;
> 
> foreach my $foo (@run_dates) {
>   print $foo;
> }
> 
> exit(0);
> 
> 
> When the test script is run on the original server, both the system cat
> call and the foreach print output the contents of the file:
> 
> ab/ => ./fileopen.pl
> 2012-03-02      incr
> 2012-03-03      full
> 2012-03-04      incr
> 2012-03-05      incr
> 2012-03-06      incr
> 2012-03-07      incr
> 2012-03-08      incr
> 2012-03-09      incr
> 2012-03-10      full
> 2012-03-11      incr
> 
> 
>  **** cat done ****
> 
> 2012-03-02      incr
> 2012-03-03      full
> 2012-03-04      incr
> 2012-03-05      incr
> 2012-03-06      incr
> 2012-03-07      incr
> 2012-03-08      incr
> 2012-03-09      incr
> 2012-03-10      full
> 2012-03-11      incr
> ab/ =>
> 
> When the test script is run on the new server, only the system cat call
> outputs the file contents, indicating that the dates.txt file contents are
> not being assigned to the @run_dates array:
> 
> ab/ => ./fileopen.pl
> 2012-03-02      incr
> 2012-03-03      full
> 2012-03-04      incr
> 2012-03-05      incr
> 2012-03-06      incr
> 2012-03-07      incr
> 2012-03-08      incr
> 2012-03-09      incr
> 2012-03-10      full
> 2012-03-11      incr
> 
> 
>  **** cat done ****
> 
> ab/ =>
> 
> 
> I've tried the "three-argument" open syntax (which doesn't seem to make a
> difference):
> 
>   open my ($DATEFILE), '+>>', $date_file || or die...;
> 
> Any ideas what's going on (and why)?
> 
> -- Michael
> 
> # Michael Doran, Systems Librarian
> # University of Texas at Arlington
> # 817-272-5326 office
> # 817-688-1926 mobile
> # do...@uta.edu
> # http://rocky.uta.edu/doran/
> 

Reply via email to