swc-windows-installer.py: Force UNIX-style \n line endings for ~/nano.rc

swc-windows-installer.py: Force UNIX-style \n line endings for ~/nano.rc

On Thu, Mar 13, 2014 at 03:37:12AM -0700, Ethan White wrote [1]:
> We now have a line ending issue resulting in:
>
>     Error reading /cygdrive/c/Users/...
>
> This is fixed by running `dos2unix` on the resulting nano.rc.

This is also mentioned in the nano FAQ [2]:

> Note that the nano.rc file must remain Unix formated in order for
> nano to unerstand it.

Since Python 3.0 and PEP 3116, Python's open() has taken a 'newline'
argument that allows you to override the default line separator for a
particular file [3,4].  However, Python 2.x does not support that
argument [5].  This commit adds a local 'open3' which uses a terrible
hack of a wrapper on Python 2 to fake that support.  It opens the file
in binary mode, and takes advantage of Python 2's lack of distinction
between str and bytes to treat the \n-terminated strings as the raw
binary output.  That's going to crash and burn if you have any
non-ASCII characters in the output content, but we explicitly set all
the components in our relative include_path, so that shouldn't be a
problem.

Another side effect of binary-mode is that we are going to get
ASCII-encoded output, not output encoded in the user's preferred
encoding (locale.getpreferredencoding [3,6]).  That's unfortunate,
because nano does the right thing and uses your locale to decode input
(at least for UTF-8 locales [7], presumably including your nano.rc
file).

[1]: https://github.com/swcarpentry/bc/pull/357#issuecomment-37518899
[2]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1
[3]: http://docs.python.org/3/library/functions.html#open
[4]: http://legacy.python.org/dev/peps/pep-3116/
[5]: http://docs.python.org/2/library/functions.html#open
[6]: http://docs.python.org/2/library/stdtypes.html#file.encoding
[7]: http://www.nano-editor.org/dist/v2.2/faq.html#5.3