nntplib downloads content with extra linebreaks

[rweth]

I am using nntplib to download archived xml messages from our internal
newsgroup. This is working fine except the download of files to the
connected server, has extra embedded
lines in them (all over the place), from the
s.body(id,afile) # body method

Is there any way to employ this library to strip out these extra
line breaks? I know this may seem trivial but they cause serious
issues when I try and employ the subsequent downloaded xml file
for a series of processes.

When I forward one of these files from Thunderbird (via the newsgroup)
to outlook and open it up, and then select "ignore extra line breaks",
and cut and paste the content .. all is well. The file is "healed".

Apart from being just a plain annoyance (all this manual steps) it
really bothers me something this trivial (the pretty-fication of
content) would throw me out of whack so badly .. also that outlook has
some simple method that magically does what I need and I cannot hack it
for myself. (not to mention how brittle
the xml processing we must have in place is .. )

First I thought it was a call to RFC 977(or below) which I cannot work
out, but which does the deed! But then I though that the content of the
forwarded msg has something in it which outlook can filter ..
because the forwarded msg is encapsulated, and likely cut off from the
news server.
(what do I know these are guesses)

 

[Klaus Alexander Seistrup]

I am using nntplib to download archived xml messages from our
internal newsgroup. This is working fine except the download
of files to the connected server, has extra embedded lines in
them (all over the place), from the
s.body(id,afile) # body method

The 'linebreaks' are probably '\r\n' pairs, so you could do a

buf.replace('\r\n', '\n')

to convert all such pairs to single LFs (buf being the buffer or
string that holds the text with 'linebreaks').

Cheers,

 

[rweth]

The 'linebreaks' are probably '\r\n' pairs, so you could do a

buf.replace('\r\n', '\n')

to convert all such pairs to single LFs (buf being the buffer or
string that holds the text with 'linebreaks').

Cheers,

Well Klaus I tried it .. sadly no joy.
Lets see if I did it the way you would have:
buf = s.body(id)[3]
# indexes 0 .. 2 contain disjoint portions but the big part is in
# [3] so .. i only did it for 3 for simplification
bufHeal = []
for aline in buf:
bufHeal.append(aline.replace('\r\n', '\n'))

fn = "c:/boing.xml"
fh = open(fn.'w')
for aline in bufHeal:
fh.write(aline)
fh.close()

This is giving me a file with no line breaks .. in fact
when I look at the elements in buf .. they don't have \r\n or \n at the
end of them .. I think the s.body(id,afile) .. does a variety of magic
to the contents of the buffer .. along with applying "some
magic template directive like an xsd file" again just guessing here.

 

[Klaus Alexander Seistrup]

for aline in buf:
bufHeal.append(aline.replace('\r\n', '\n'))

What does one single aline look like?

s.body(id,afile)

Does the 'afile' contain a filename or a filepointer?

Cheers,

 

[rweth]

What does one single aline look like?


Does the 'afile' contain a filename or a filepointer?

Cheers,

so afile contains a filename.
One single aline looks like so:
'</rme:SoftwareIdentity>'

 

[Klaus Alexander Seistrup]

so afile contains a filename.
One single aline looks like so:
'</rme:SoftwareIdentity>'

Beats me where those empty lines come from, it doesn't seem to
happen in nntplib.

Does the same thing happen if you pass .body() a filepointer?

Cheers,