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

The code below is the begining of a graphical poll script I am writing. It is working well from the command line so far. My question is this: The output file has linebreaks whose origin is a mystery to me. Can anyone tell me why the results look like this:
purple
:2:blue
:1:red
:2

[download]
Is this some sort of default column width formatting?
TIA
jg
#!/usr/bin/perl -w
use strict;

#use Fcntl ':flock';  # import LOCK_* constants

use CGI;
use CGI::Carp qw/fatalsToBrowser /;

my $q = CGI->new();

######### CONFIG #############
my $results_file ="c:\\windows\\desktop\\survey.poll";
my (%data, @file);
##############################
print "Color choice: red, blue, or purple?\n";
my $input = <STDIN>;
chomp $input;

get_data();

exit;





sub get_data {
    if (-e $results_file){
        open (FH, "+< $results_file") or die "where's the damn file? :
+ $!";
    } else {
        open (FH, "> $results_file") or die "where's the damn file? : 
+$!";
    }
    #flock (FH,LOCK_EX) or die "Couldn't flock: $!";

    $_ = <FH>;
    chomp;
    if ($_) {
        my @file= split(/:/);
        %data = @file;
    }

    $data{$input}++;

    seek FH, 0, 0;
    truncate (FH,0) or die "Can't truncate: $!";
    @file = join(":",%data);
    print FH @file;
    #flock(FH,LOCK_UN);  #unlock the file

    close FH or die "close damn you : $!";
}

[download]
_____________________________________________________
If it gets a little bit out of hand sometimes, don't let it fool you into thinkin' you don't care.TvZ

Replies are listed 'Best First'.
Re: Where are these newlines coming from?
by vladb (Vicar) on Feb 15, 2002 at 20:17 UTC
    I tried running your code on my box (Solaris 8, Perl5) and it worked fine. The output that I got was this: 
    blue:2:purple:1:green:1:red:2
    this is after I ran your script 4 times, each time providing a different answer.

    This problem of yours might be related to Windows only? Hmm...

    "There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
[reply]
Re: Where are these newlines coming from?
by jerrygarciuh (Curate) on Feb 15, 2002 at 20:15 UTC
    VirtualSue has kindly pointed out that the newlines disappear if CGI is not invoked. While CGI is not useful in this context, it will be need for later portions of the script. So new question, why would CGI be inserting these newlines? Admittedly chomping them takes care of the problem, but I am still curious as to why it is happening.
    TIA
    jg
    _____________________________________________________
    If it gets a little bit out of hand sometimes, don't let it fool you into thinkin' you don't care.TvZ
[reply]
[d/l]
[select]
      That's not what I meant. :) When we discussed it in the chatterbox, you said

      another interesting clue is that now UltraEdit isn't asking if I want it converted to DOS format anymore

      I interpreted that to mean that you were doing some cross-platform dos-unix stuff, and chomp won't chomp correctly if you run it on unix but feed it input with ms-dos style newlines. That's because unix uses LF for newline, and ms-dos uses CRLF. I have no idea if this applies to what you were doing, but your program works fine on my solaris box, with or without CGI.
[reply]
Re: Where are these newlines coming from?
by Speedy (Monk) on Feb 15, 2002 at 23:50 UTC
    I've run into these "ending" problems with the input from Web browser "textarea" form boxes with browsers running on different platforms -- on say Windows, Linux and Macintosh.

    In a form textarea box most Windows browsers (esp. MS IE) after an "enter" or "return" produce a lfcr, on Linux just a lf, and on a Mac browser just a cr (since each plaform developers had differing notions of what constitutes a line break).

    Below is the rather inelegant code I used then to display the results on the browser screen (which being HTML wants a <br>, and in the file system of the UNIX box the data were being saved to, which whats a '\n' or lf.

    $phrases was the return parameter from a browser textarea box which could have one or more lines with endings generated by the "enter" key.

    #  Account for differences in browser returns 
#  Replace \r\n, \r, or \n with <br>
 
    $lf = chr(10);
    $cr = chr(13);
    $phrases =~ s/$lf/<br>/g;
    $phrases =~ s/$cr/<br>/g;

#  In case you were on Windows and not UNIX nor MAC,
#  now have two <br>'s rather than one  
   $phrases =~ s/<br><br>/<br>/g;

#  Show $html_phrases in text box of browser
   $html_phrases = $phrases;

#  Fix $phrases for storage in UNIX file
   $phrases =~ s/<br>/\\n/g;

    [download]
    Must be an easier way, but this got the list in $phrases displayed properly in the browser, and saved with a single "\n" for line endings regardless of which browser it came from.

    Live in the moment
[reply]
[d/l]
Re: Where are these newlines coming from?
by theguvnor (Chaplain) on Feb 15, 2002 at 20:55 UTC
    Is it possible that the results file you're starting off from has the newlines in there?

    ..Guv

[reply]
Re: Where are these newlines coming from?
by Dog and Pony (Priest) on Feb 16, 2002 at 11:32 UTC
    Well, for the first thing, chomp removes whatever is in $/, right? And CGI.pm does manipulate that variable around, although it uses local in some places, and restores the old value in other places, so without premature returning, I can't see how that would affect it. $/ should be properly set on whatever platform you are running your script on, but if you like, you could try to set it manually to whatever is fitting, before you chomp. Probably something like $/ = "\r\n"; on windows.

    If the file you are reading from contains newlines, the below code (yours) would not work. It would only chomp the last newline out. 

        $_ = <FH>;
    chomp;
    if ($_) {
        my @file= split(/:/);
        %data = @file;
    }

    [download]
    You would need to do something such as: 
        my @file = <FH>;
    chomp @file;
    %data = split(/:/, join('', @file));

    [download]
    That would read all the separate lines, chomp each of them and then join the result together before splitting on /:/ like before. If you have prepared the file you are testing against by hand, or moved it from another platform, this might well be the issue. Also, if you are moving a file between platforms via ftp, transfer them in ASCII mode, for newline translations.

    Then, I think this code looks a bit curious: 

        @file = join(":",%data);
    print FH @file;

    [download]
    Don't you mean something like: 
        my $file = join(":", %data);
    print FH $file;

    [download]
    I don't think that matters all that much though.

    I just got up, so I'm a bit confused right now, but I'd look at these issues anyways. :)

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom