duplicity-team team mailing list archive

[Aaron <lists@xxxxxxxxxxxxxxxxxx>]

Sorry Ken, I had already submitted my branch for merging before I saw this.

On 01/12/17 20:43, Kenneth Loafman wrote:
> Hi Aaron,
>
> Not sure about adding ANSI_X3.4-1968. That would mean that the system 
> indeed hand locale specified properly.
>
> The values 'ascii' and None were returned when locale was not 
> specified at all (detached or cron jobs on some setups).  ANSI implies 
> a proper locale setting.
>
> ...Ken
I am not sure I see the conceptual distinction between ascii and 
ANSI_X3.4-1968 in this context. I believe ANSI_X3.4-1968 is an alias for 
ASCII and is often also a default when things are misconfigured -- a 
quick Google brings up a bunch of "why does x return ANSI_X3.4-1968 
instead of y", e.g.:
https://stackoverflow.com/questions/44344458/why-does-locale-getpreferredencoding-return-ansi-x3-4-1968-instead-of-utf-8
"Since in your locale |LC_ALL| is not set, the ASCII default (“ANSI 
X3.4-1968”) is used (this might answer your question in the title)."

I agree there is some risk of a system deliberately configured as 
ANSI_X3.4-1968 will be misinterpreted as UTF-8, but think that same risk 
exists with the recent change to make 'ascii' default to UTF-8. As the 
code/my branch is currently, this global is only used for reading 
encoded text and, as UTF-8 is a superset of ascii/ANSI_X3.4-1968, I 
cannot see how it could go wrong unless/until somebody also uses that 
global for writing.

If you do not want to merge this approach, I would really appreciate 
further thoughts on how else to get past the pexpect/testing environment 
being misdetected as ANSI_X3.4-1968, as I'm at a bit of a loss.

Kind regards,

Aaron