Output files use Unix line endings on Windows

[GoogleCodeExporter]

This bug is caused by us relying on Python converting \n to \r\n on Windows
but that doesn't work because we open output files in binary mode. This
isn't such a big deal for the framework itself because browsers can handle
both line endings. The main reason this needs to be fixed is that the bug
affects also RIDE:
http://code.google.com/p/robotframework-ride/issues/detail?id=421

Original issue reported on code.google.com by pekka.klarck on 25 Mar 2010 at 4:30

[GoogleCodeExporter]

Descoped from 2.5.

Original comment by KariH...@gmail.com on 20 Apr 2010 at 8:10

• Removed labels: Target-2.5

[GoogleCodeExporter]

Original comment by robotframework@gmail.com on 2 Dec 2011 at 9:25

• Added labels: Target-2.7

[GoogleCodeExporter]

This has now been fixed and acceptance tested.

While looking at this I learned something new about how Python handles lines 
separators:

1) If file is opened in text mode ('w', 'r' or 'a') on Windows, '\n' is 
automatically translated to '\r\n' when writing and '\r\n' to '\n' when 
reading. No translation is done on other platforms.

2) If file is opened in binary mode ('wb', 'rb' or 'ab'), no translation is 
done on any platform.

3) codecs.open forces binary mode to prevent possible data corruption. That is 
highly annoying and also stupid because text mode would be safe with most 
encodings (and is safe with UTF-8)). This annoyance means that all '\n' 
characters must be replaced with os.linesep when reading/writing. That is often 
more work than using normal open and encoding/decoding content to UTF-8 when 
writing/reading.

Original comment by pekka.klarck on 19 Dec 2011 at 4:21

[GoogleCodeExporter]

Original comment by pekka.klarck on 19 Dec 2011 at 4:27

• Changed state: Done

[GoogleCodeExporter]

Original comment by pekka.klarck on 12 Jan 2012 at 9:29

• Added labels: alpha1