At 10:51 -0500 02.12.2001, Patrick Galbraith wrote:
>in the template tool, a simple /\x0d/\n/ applied to what is going to be
>written to file upon pulling them out of the database would solve this
>particular issue.
No, it wouldn't. Then you would have \n\n instead of \n for each CRLF.
You would need "s/\015\012/\n/g" (I prefer octal to hex, since I believe it
is more universally understood, but whatever), not just a mere
"s/\015/\n/g".
>Right now, we're writing to file the contents that are
>literally in the db (which includes the LF/CRLF '^M's). Trying to edit
>these files with the ^M in them is a little troublesome.
Exactly. So the simple regex above would solve it. If we did this, we
could also then do "s/\n/\015\012/g" on the data before writing TO the
database, so the CRLF would be saved back in the database. Although I
doubt it would matter, it wouldn't hurt (as long as the data was already
only LF ... we might want to do something like "$data =~ s/\n/\015\012/g
unless $data =~ /\015\012/", just to make sure we are not converting CRLF
data to CRCRLF).
--
Chris Nandor pu...@po... http://pudge.net/
Open Source Development Network pu...@os... http://osdn.com/
|