Fix getting pandoc version number

[takluyver]

Allowing for non-ascii home directory on Windows. We only need to decode the first line, not the whole output.

Closes gh-621

[mpacer]

Why did you get rid of universal_newlines=True? Just curious.

[mpacer]

Is the issue that we just need to get it to be in the defaultlocale so that we can use that information to implicitly decode the string to ascii?

[takluyver]

universal_newlines in subprocess actually means 'decode the output from this process using the locale default encoding'. It's presumably like that for historical reasons, because it makes absolutely no sense now.

The issue in #621 was that pandoc produces output that's not in the locale encoding. It may be using UTF-8 in all cases, but I don't think that really matters. The version number which we're trying to get is probably always going to be made up of ascii characters.

So the change here tells subprocess not to decode the output, so we get bytes back from it. Then we take the first line, and decode that ourselves to get the version number. The bytes.splitlines() method already copes with the different newline conventions, so we don't need subprocess to handle that.

[mpacer]

Got it!