Nailing an elusive unicode bug, and a heads up

[Ian Bruene]

Several months ago when I added the unit display feature there was a bug 
that caused ntpq to crash with a unicode error for no apparent reason. 
The crash was never replicated, but I added some debugging statements in 
hope of catching it. Someday.

In the last week during the release delay Gary and I stumbled on a 
little known feature of Python where the encoding of the standard 
streams can be changed by an environment variable. Tests unearthed a 
number of unicode bugs due to this in both ntpq and ntpmon, ntpq was 
fixed to detect via sys.stdout.encoding if it was talking over UTF-8 and 
if not to use a wrapper to force UTF-8 output. ntpmon unfortunately 
could not be fixed in this way; it uses the curses library which 
interfered with this solution. ntpmon now downgrades to a non-unicode 
version if it encounters this problem.

At the end of last week I got another bug report for ntpq from jasonium 
which matched the old never replicated bug. Today I got the full 
traceback from him and discovered that sys.stdout.encoding sometimes 
lies, sometimes claiming that it is UTF-8 when it is not. ntpq now 
always forces UTF-8 regardless of what python claims it is.

Be advised: sys.stdwhatever.encoding can be fake news.

-- 
In the end; what separates a Man, from a Slave? Money? Power?
No. A Man Chooses, a Slave Obeys. -- Andrew Ryan