We have a comm break down.   I actually misread your report. (this is why test cases and versions really do matter.)   It was the KML writer that I bozoed in 1.4, not the GPX writer.

The GPX writer does encode them as I describe:

 echo "1,2,Xyx<hello>" | ./gpsbabel -i csv -f - -o gpx -F -
<?xml version="1.0" encoding="UTF-8"?>
  creator="GPSBabel - http://www.gpsbabel.org"
  xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">
<bounds minlat="1.000000000" minlon="2.000000000" maxlat="1.000000000" maxlon="2.000000000"/>
<wpt lat="1.000000000" lon="2.000000000">

On Sat, Aug 28, 2010 at 12:47 AM, Hans-Georg Michna <hans-georg@michna.com> wrote:
> It's a solution, but not the only one.   Post 1.4.2, it will
> look like:
> bash-3.2$ echo "1,2,Xyx<hello>" | ./gpsbabel -i csv -f - -o
> kml -F - | grep hello
>        <name>Xyx&lt;hello&gt;</name>

Ah, so the problem was already recognized!

I fear that is not a complete solution. It does prevent breaking
XML, but when you load such a GPX file into any other program,
like Garmin's MapSource, you will actually get:


rather than:


because other programs have no idea in what way the text was
encoded or that it was encoded at all. To my knowledge the GPX
standard does not prescribe encoding.

GPX prescribes XML.  XML prescribes entity encoding and that is a legal encoding.   Validate it and see:

echo "1,2,Xyx<hello>" | ./gpsbabel -i csv -f - -o gpx -F  /tmp/blah && SAX2Count -f /tmp/blah
/tmp/blah: 8158 ms (7 elems, 9 attrs, 14 spaces, 50 chars)

If Mapsource gets this wrong (and it's late enough I don't want to boot Windows to see) then we need to rattle Garmin's cage.

inside the text has to be altered. (CDATA, unfortunately, is not
something like a transparent encoding. Its inventors have not
thought it through to the end.)

Yes, it's a legendary botch - and one reason why we do entity encoding instead of CDATA quoting when we can.