Not printing to file, but print to screen ok

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

It's doing my head in! Creates the new file but always 0 bytes - what I'm expecting to see in the file prints ok to screen. Sorry for being obtuse...

#action to edit===

if ($action =~ /edit/) {
  my ($newline, $list);
  if ($action eq 'edit1') {
    $newline = join "\n", $job11, $job12, $job13, $job14, $job15;
    $list = $list1;
  } elsif ($action eq 'edit2') {
    $newline = join "\n", $job21, $job22, $job23, $job24, $job25;
    $newline = $newline . "\n";
    $list = $list2;
  } else {
    print 'Sorry - did not understand this behaviour, please hit the b
+ack button and try again';
    exit;
  }
    open FH, '>', "$list.tmp" or die "$list == $!";
    print FH $newline;
    close FH;
    
    print $newline;
    exit;

}
[download]

Comment on Not printing to file, but print to screen ok Download Code

Replies are listed 'Best First'.
Re: Not printing to file, but print to screen ok by toolic (Bishop) on Mar 17, 2010 at 18:36 UTC
I don't see anything obvious with your code. Try taking a few steps backwards, and just run the following code. It should create a file named 'foo.tmp' with just one line (bar). It also checks the success of print. Do you get any errors? `use strict; use warnings; my $list = 'foo'; my $newline = "bar\n"; open FH, '>', "$list.tmp" or die "$list == $!"; print FH $newline or die "Error print: $!"; close FH; print $newline;` [download]	[reply] [d/l]
Re^2: Not printing to file, but print to screen ok by almut (Canon) on Mar 17, 2010 at 18:45 UTC
Maybe also check the `close` `close FH or warn "close failed!";` [download] (close only returns true if IO buffers were successfully flushed)	[reply] [d/l] [select]
Re: Not printing to file, but print to screen ok by Marshall (Canon) on Mar 18, 2010 at 01:02 UTC
It appears to me that this partial code that is in a loop. Every time you hit `open FH, '>', "$list.tmp"` that will start a new file with zero length. If $newline happens to be "null", nothing will be written to this file. It could be that your program for whatever reason is "tripping" over this open statement again. A more normal order of things would be to open the output file much earlier. The reason for this is that we don't want to do a lot processing only to find out later that we can't write the result because we don't have the correct file permissions or path! I have seen programs bomb after 2-5 days of running because of this! So bad idea. If your program doesn't run for a "long time", I see no reason the close the file handle, FH. When your Perl program exits, the OS will close that file handle. You can open a new file with the same File Handle and the OS will "recycle it". No problem. Anyway if your program just uses a couple of file handles and runs for some seconds or minutes, there is no need to "close" the file which releases some resources back to the OS. There will be at MOST one line in your FH output file. Open this file handle earlier.	[reply] [d/l]
Re: Not printing to file, but print to screen ok by jonnyfolk (Vicar) on Mar 17, 2010 at 22:29 UTC
I'm wondering if you're on a shared hosting account - try checking that your quota is not exceeded. If it is one of the consequences is sometimes to write empty files. Get your quota increased!!	[reply]