John A Meinel пишет:
> Robert Collins wrote:
>> Review: Needs Information
>> This doesn't make sense: why would we want to have an output encoding that isn't compatible with the operating systems encoding? I'm channelling Martin[gz] here I think - I recall him asking this question in IRC, and I think its a good question.
>
> Incorrect auto-detection. (Fairly common, Mac hasn't traditionally
> detected well, neither FreeBSD, etc.)
>
> Output to a file.
>
> bzr log | less
> vs
> bzr log > content.txt
>
> (On Windows, the former should probably use Terminal encoding, but the
> later should use locale.getpreferredencoding())
Exactly.
> I think the big thing is having this as a step along the way to being
> able to supply it on a per-command basis.
On UDS I've talked with Martin and proposed global command-line option
--encoding for this, e.g.:
bzr --encoding utf-8 log > file.txt
But if this patch is the first step towards this goal, it's ok.
John A Meinel пишет: getpreferredenc oding() )
> Robert Collins wrote:
>> Review: Needs Information
>> This doesn't make sense: why would we want to have an output encoding that isn't compatible with the operating systems encoding? I'm channelling Martin[gz] here I think - I recall him asking this question in IRC, and I think its a good question.
>
> Incorrect auto-detection. (Fairly common, Mac hasn't traditionally
> detected well, neither FreeBSD, etc.)
>
> Output to a file.
>
> bzr log | less
> vs
> bzr log > content.txt
>
> (On Windows, the former should probably use Terminal encoding, but the
> later should use locale.
Exactly.
> I think the big thing is having this as a step along the way to being
> able to supply it on a per-command basis.
On UDS I've talked with Martin and proposed global command-line option
--encoding for this, e.g.:
bzr --encoding utf-8 log > file.txt
But if this patch is the first step towards this goal, it's ok.