Updates:
Status: Duplicate
Mergedinto: 616
Comment #5 on issue 594 by pekka.klarck: RobotFramework 2.5 does not
support encoding "c", which is default for some platforms
http://code.google.com/p/robotframework/issues/detail?id=594
I believe I now know what's going on:
1) Python sets sys.stdout/stdin.encoding depending on LANG (and possible
other environment variables) and handles the special C encoding at that
point. I don't know why Python and Jython handle C differently, though.
2) Normally when Robot Framework is run, it gets the encoding from
sys.stdout/stdin.encoding. It's fine if LANG is C because Python takes care
of that. This is the reason we failed to reproduce this.
3) If stdout and stdin are redirected, and possibly on some other
situations too, Python sets sys.stdout/stdin.encoding to None. In this
case, on Unixes, RF tries to get the encoding to use based on the
environment variables. If it finds that LANG is C, it will use it as-is
which causes the look-up error you got. The same error is got when running
this command: `python -c "'x'.encode('C')"`.
A fix for this is that RF should verify the encoding it gets from the
environment. I just submitted issue 616 about that based on another error
report we got. Because the underlying bug seems to be the same, I'll
resolve this issue as a dupe of 616. The actual problem should be fixed in
RF 2.5.2 next week.
