[Xastir] Fetch FINDU Trail problem/question

[Kevin Paetzold]

It seems I am unable to display fetched findu trails any longer.  It used
to work.  This is true running Fedora 7 as well as with CYGWIN.
I spent several hours in gdb and poking around with this today
trying to figure it out.  I am sending this msg because I think
what I am seeing may be more obvious to one of the developers (before
I continue this foray through the code :-).

When the trail in question is being fetched the ./xastir/tmp/map.log
file ends up (after sed was invoked) with all the html code still
in the file and (what seems to me) a ">" where a ">" should be
in each packet.  As below:

K1KWP-14>APRS,WIDE1,WIDE2-1,qAo,NE1B:@165247h4216.02N/07143.58Wk240/014 
/A=000554Listening to WWW.MMRA.ORG Repeaters   <br>
K1KWP-14&gt;APRS,WIDE1-1,WIDE2-1,qAo,K1KWP-1:@165443h4216.57N/07143.82Wk289/016 
/A=000554Listening to WWW.MMRA.ORG Repeaters   <br>
K1KWP-14&gt;APRS,WIDE1-1,WIDE2-1,qAo,K1KWP-1:/221656z4216.52N/07144.60W/270/000 
/A=000449   <br>
K1KWP-14&gt;APRS,WIDE1-1,WIDE2-1,qAo,K1KWP-1:@165702h4216.52N/07144.77Wk004/011 
/A=000430Listening to WWW.MMRA.ORG Repeaters   <br>
K1KWP-14&gt;APRS,WIDE1-1,WIDE2-1,qAo,K1KWP-1:@165754h4216.57N/07144.83Wk277/009 
/A=000407Listening to WWW.MMRA.ORG Repeaters   <br>
K1KWP-14&gt;APRS,WIDE1-1,WIDE2-1,qAo,K1KWP-1:@165914h4216.58N/07144.77Wk000/009 
/A=000413Listening to WWW.MMRA.ORG Repeaters   <br>

The track from the above packets is not displayed and through the
debug messages it seems that these packets do not get successfully
parsed.  Indeed if I change the above to substitute a ">"  for the "&gt;"
(and I also stripped out the html code) I can read the file through
File->Open Log File and see the track.

Imagine my surprise when I issued the same url to Firefox as xastir was
generating and the resulting display appeared correct (i.e.. with the ">").
However viewing source for the resulting display shows that the actual
data returned really has "&gt;" in each packet!  Firefox is doing some
kind of translation that makes it look correct when displayed.  Is this
something that the invocation of sed was supposed to fix? Is this some
unicode issue?

73,

Kevin (K1KWP)