Instead of a gripe, a memory-jog.
Wed Sep 22 00:35:00 GMT 2010
SJ Wright wrote:
> Corinna Vinschen wrote:
>> On Sep 18 07:00, SJ Wright wrote:
>>> Having recently by accident trashed my home folder, and having had
>>> to rebuild from one saved from a much older install (1.7.0 or even
>>> earlier), I noticed my man pages were again displaying with garbage
>>> text in between the readable text -- nonprintable characters,
>>> Unicode litter and the like. I remembered Corinna Vinschen had
>>> posted something quite a while back in a topic thread that dealt
>>> with this issue; I am sure it made it into the archives for this
>>> list, but I wasn't able to find it. I vaguely recalled one detail
>>> had something to do with setting one's environment variable to C
>>> instead of C.utf_8 or even en_us.utf8.
>> Ouch. Wrong on both accounts. Either "C.UTF-8, or "C.utf-8", or
>> "C.utf8", or "en_US.UTF-8" or "en_US.utf-8" or "en_US.utf8". Dash yes,
>> underscore no. The territory must be written in uppercase.
>> The User's Guide might be a good start:
> 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
> they hadn't been when I either had *no* LANG variable set or a
> correctly-written one. So now it's fixed. Thanks again.
> SJ Wright
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
text" -- 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Ã¢â¬Â
I just looked at the wget man page (which is, not remarkably, still free
of drone text), and I notice there's a command that can be entered in
.wgetrc that seems to sync LANG with the application's function. Or does
it. I'm referring to the "local_encoding" command. It would make sense
that if LANG gets changed, and an encoding-sensitive app such as wget is
left "one step behind," so to speak, in that process, then there would
be a command or configuration option to help it "catch up." This
presumes I'm reading the man page right. I acknowledge it may have
nothing to do with how wget displays the stages of the download process;
I would rather know for sure that this is the case. In the meantime,
I'll settle for running with the "-nv" option which may just give me
clean text by some means or another. I'm thinking it won't, but that's
four or five scrollback lines I'm saving at 80x36 at any rate.
Just keeping everyone apprised.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin