Instead of a gripe, a memory-jog.
Thu Sep 23 02:39:00 GMT 2010
On 22 September 2010 14:29, SJ Wright wrote:
> Andy Koppe wrote:
>> On 22 September 2010 00:29, SJ Wright wrote:
>>>> Yes. I noticed where I had the territory mis-cased the next time I ran
>>>> wget. In the line that identified the file and URL for each download,
>>>> double-quotes and other punctuation became garbage characters, where
>>>> hadn't been when I either had *no* LANG variable set or a
>>>> one. So now it's fixed. Thanks again.
>> If LANG (and also LC_ALL and LC_CTYPE) aren't set, Cygwin defaults to
>> UTF-8. It's better to have it set though, because some programs such
>> as emacs default to plain ol' ASCII if the locale isn't set. That's
>> why LANG is set to C.UTF-8 during login shell startup (by
>> /etc/defaults/etc/profile.d/lang.sh). In other words, you shouldn't
>> have to worry about it.
>>> Spoke too soon on the wget matter. Since setting a LANG variable in the
>>> first place (and evidently the right place, or else this wouldn't be a
>>> "matter"), I've been seeing garbage text -- I prefer to call it "drone
>>> -- in place of quotation marks during normal (non-verbose and not set to
>>> "quiet") downloads. Here's a sample:
>>>> Saving to: â€œgae77-7748-244-958stck.jpgâ€
>> That looks like wget is using UTF-8 yet your terminal is using
>> ISO-8859-1. The Cygwin console as well as all the terminals shipped
>> with Cygwin (except for rxvt) use UTF-8 by default. With other
>> terminals, you might have to select it somewhere in their options.
> Well, my LANG is C.UTF-8, and the garbage in wget turned back into single-
> and double-quotes as soon as I added the command to .wgetrc I mentioned. So
> it turns out, at least in my case, that "local_encoding=UTF-8" does
> something positive with how commands/running task steps are displayed.
The use of fancy Unicode quotes in wget is actually controlled by the
locale setting, i.e. LANG and relatives. LANG=C.UTF-8 gives you ASCII
quotes, whereas LANG=en_US.UTF-8 results in Unicode quotes. As far as
I can see, the local_encoding setting has no bearing on this.
> This was, coincidentally, in rxvt that all of this was happening. I've yet to try
> it in MinTTY. I don't expect much of a difference: these are 'peripheral'
> variables set and if a UTF-8 works from two directions in a term that isn't
> built to like it, then 'how much better should it be in one that does?' is
> not even a question worth asking, imo.
Well, if you're not using anything beyond ASCII, then no, rxvt's lack
of UTF-8 support doesn't matter. But don't come back crying when you
do encounter more funny letters.
Rxvt actually uses CP1252, which is MS's extended version of
ISO-8859-1, hence appropriate locale settings for rxvt use one of
those charsets, e.g. LANG=en_US.CP1252.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin