cowsay
cowsay copied to clipboard
encoding on windows
Hey @noamross @richfitz @trinker @leeper
We're having problems with this pkg on windows. E.g.,
But on unix does
say("asdfsf", "longcat", length = 4)
-----
asdfsf
------
\
\
.ハ,,ハ
( ゚ω゚)
|つ つ
| |
| |
| |
| |
U " U
This is what longcat is in the pkg:
longcat <-
'
\n ----- \n %s \n ------ \n \\\ \n \\\
.\uFF8A,,\uFF8A
( \uFF9F\u03C9\uFF9F)
|\u3064 \u3064
%s
U " U
'
Any way to fix this to work on windows?
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.
thanks @leeper - will keep digging
@gavinsimpson any help on the encoding issue on Windows?
Sorry, Scott, I don't currently have access to a windows box
meh, maybe we'll just put this on CRAN and say it doesn't work on Windows, seem okay @leeper @richfitz @gavinsimpson
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 https://github.com/sckott/cowsay/issues/9#issuecomment-61591349.
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
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?
@ateucher what if you use type="string"
, then call message()
, etc. manually after it comes back? does that work okay?
Nope. I think as soon as message
/warning
get hold of it, it kills it:
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
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!
i think maybe we should just go with the solution you've already done - and push to CRAN!
Agreed! It does function on Windows, so we should go for it.
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?
@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
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.
I'll just remove the examples that don't work on windows...
Yeah, good idea. That's the simplest solution