Instead of a gripe, a memory-jog.

SJ Wright
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:
>> Corinna
> 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.

Steve W.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list