open my $data, '+<', $INFILE1 or die "can't open\n$INFILE1\n";
    while (<$data>) {
    ...;
    my ( $data ) = split (',',) ;
    ...
    close $data or die "can't close\n$INFILE1\n"; 
}
[download]

Apart from any other problem(s), the  $data lexical filehandle you're trying to close is not the one you open-ed and is not a filehandle at all. It is a lexical of the same name that was created as a part of the split statement and that hides or "shadows" the filehandle lexical. Inclusion of the  $! error variable in the die expression of the close statement might have alerted you to the fact that it wasn't a filehandle. (See  $! in Error Variables in perlvar.)

... if the first column is not empty, then it should print out to the same file ...

The statement
    print "$_ \n";
prints to the default filehandle, which I assume would be  STDOUT given the code we are shown in the OP. (Update: select can change this default.)

hi john.tm,

I am trying to open a file for reading and writing. i open the csv file

Think of CSV files? At least think Text::CSV or Text::CSV_XS and you will do away with "hand-picking" of values.

Take a look at the Tie::File module. If you examine how it works, you will see how this is done.

Generally, one reads a file into some data structure (an array being the most simple) then unlinks the original file(deletes it) then create and write back to a nee file of the same name.

A google search will bring you right back here to read from a file and write into the same file which examines the methods and it's whys and wherefores.

Hope that is helpful...

I wouldn't call that the general solution, as one of its most likely failure modes would result in data loss (imagine loss of power before the new file is written, or an inability to write the new file).

A more common pattern is the one that Perl's -i switch accomplishes for one-liners: Rename the input file, open the output file in the name of the original input file, open the renamed input file, iterate over the input, write to the output, close the output, and as a final step, unlink the renamed input.

With that pattern rename is atomic, and unlink happens only after the new output file is successfully closed.




Dave

Good point. I did not do a very good job of articulating that.

Thanks for the correction... I appreciate it.

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

A cursory strace perl -pi reveals a more sloppy pattern than described, however. I see open/unlink/open/read+write/close/close. The unlinked source file is still readable; it gets released upon close.

A relatively safe update sequence is: mkstemp/read+write/fsync/rename. The final rename is atomic, but that itself does not prevent races with multiple updaters (of course).