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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
