[Za-pm] creating new file one line at a time

[Anne Wainwright]

Hello, James & Leon,

That was actually it. The original data originated in an old (clue) dos
database. I had a number of perl scripts developed over time to work
with the files in dos/win, change, repair, transform,  like
clue2txt, clue2pdx, & clue2htm. The clue2sql was developed from these,
but in the final line I had left in the \r\n necessary for a file being
used in dos.

Postgresql had swallowed the delimited.txt until now, \r and all, and
only when trying to add an additional field delimiter did it become
apparent.

So having now realised that and modified to suit, all appears
well.

Thanks for your ideas and input.

Shame that this group is quiet, but it always comes up with an answer
when needed!

I was surprised to find za-pm active still, it is not currently listed
on the 

http://www.pm.org/

site.

Anne


On Sun, 07 Mar 2010 19:17:04 -0500
James E Keenan <jkeen at verizon.net> wrote:

> (I didn't realize that my first post only went to Anne.  So, for the  
> benefit of the list ...)
> 
> 
> In Perl, when you read a record like this, you are reading it
> newline and all.  So what we almost always do is to first clear off
> the newline.  Then we analyze/rewrite the line as needed.  Then we
> print it to the write handle with a newline.
> 
> Try:
> 
> while (<IMPORT>) {
>    chomp;
>    print RESULT "$_|\n";
> }
> 
> Note:  You are using global filehandles here.  Lexically scoped  
> filehandles have been available in Perl since (I think) the  
> introduction of 5.8 in 2002.  They're considered "best practice."
> So what you really want in your 'open' statements is:
> 
> open my $IMPORT, '<', "import.txt" ...
> open my $RESULT, '>', "delimited.txt"
> 
> ... which also illustrates the 3-argument form of 'open', which is  
> often (though perhaps not universally) also considered best practice.
> 
> 
> And now to follow up further ...
> 
> 
> I know that at my $dayjob we often have input of character-delimited  
> records that arrives in DOS format.  What that means is that the  
> lines actually end in '\r\n'.  One of the other programmers wrote a  
> function called 'chew()' that essentially does this:
> 
> $line =~ s/(.*)(\r\n)*/$1/;
> 
> In your case, chomp may not be eliminating a final \r, so when you  
> append a pipe it appears on the next line.
> 
> _______________________________________________
> Za-pm mailing list
> Za-pm at pm.org
> http://mail.pm.org/mailman/listinfo/za-pm