encoding on windows about cowsay

[leeper]

No solution, but returning a character string and printing with cat works in Rgui but not the console. E.g., cat(say("asdfsf", "longcat", length = 4, type="string")). So clearly Rgui is doing something to unicode character strings that it does not do under message/warning/error and R itself does not do at all.

[sckott]

thanks @leeper - will keep digging

[sckott]

@gavinsimpson any help on the encoding issue on Windows?

[richfitz]

Sorry, Scott, I don't currently have access to a windows box

[sckott]

meh, maybe we'll just put this on CRAN and say it doesn't work on Windows, seem okay @leeper @richfitz @gavinsimpson

[leeper]

I don't have time at the moment to try to figure it out, so that's fine.
Maybe putting it on CRAN will catch the attention of someone who can make
it work.

On Tue, Nov 4, 2014 at 5:13 AM, Scott Chamberlain [email protected]
wrote:

meh, maybe we'll just put this on CRAN and say it doesn't work on Windows,
seem okay @leeper https://github.com/leeper @richfitz
https://github.com/richfitz @gavinsimpson
https://github.com/gavinsimpson

—
Reply to this email directly or view it on GitHub
#9 (comment).

[sckott]

Poll:

doesn't work:

• windows 8.1, R 3.1.1 https://twitter.com/soodoku/status/530128301738983424
• my virtualbox windows: windows 8.?, R 3.1.1

[ateucher]

I think the pertinent information is in here: http://cran.cnr.berkeley.edu/doc/manuals/r-devel/R-ints.html#Encodings-for-CHARSXPs.

Basically it seems like, on Windows, functions which use C code like message and warning can't properly deal with UTF-8 strings due to the Windows C compiler. It looks like cat and print have some sort of escape which gets around this... which is consistent with what @leeper observed (I experienced the same behaviour).

I played around with iconv a bit to no avail. I don't think you can catch and modify a message or warning after it's called and before it's printed?

[sckott]

@ateucher what if you use type="string", then call message(), etc. manually after it comes back? does that work okay?

[ateucher]

Nope. I think as soon as message/warning get hold of it, it kills it:

[sckott]

okay, boo, well, not sure what to do then.

could just not use unicode characters and use the closest ascii characters...but you've kind of solved this another way by not using those that have unicode on windows

[ateucher]

Yeah, could do gsub on the \u strings only if os == windows. But I wouldn't want to do it wholesale and make them look worse for everybody else. Some of those might be hard to find decent replacements for though!

[sckott]

i think maybe we should just go with the solution you've already done - and push to CRAN!

[ateucher]

Agreed! It does function on Windows, so we should go for it.

[ateucher]

So I guess this isn't really fixed yet - the appveyor build is failing on the examples using non-ascii characters (anxiouscat). Would you want to put those in a dontrun section?

[sckott]

@ateucher it seems like its an issue with the match.arg https://ci.appveyor.com/project/sckott/cowsay/build/1.0.218#L366 or am i looking at it wrong

[ateucher]

It is, but because on Windows get_who() removes anxiouscat etc from the vector whose names are used in match.arg. That's why they all work on Linux/Mac, but the animals with non-ASCII throw an error on Windows.

[sckott]

I'll just remove the examples that don't work on windows...

[ateucher]

Yeah, good idea. That's the simplest solution