How to make 8859-1 work again

[jc at trillian.mit.edu (John Chambers)]

Charles C. Bennett, Jr. wrote:
| > I tought  that   the jaz  scsi  ID was  the problem  and   switch it  to
| > scsi ID 7 but  didn)B?t work

This was the latest of  what  has  become  a  growing  problem:   The
original  message obviously contained "but didn't work", but it comes
out on this xterm as "but didn\b4t work".  When I first looked at  it
with  the  mh mail reader, it looked like "but didn<B4>t work", where
the <B$> was inverse video.

Now, I've seen xterms work just fine with the 8859-1 char set, and it
oughta  work  here,  too, because when I run "xrdb -query" the output
includes the line:

xterm*font: -b&h-lucidatypewriter-medium-r-normal-sans-10-0-75-75-m-0-iso8859-1

This would seem to say that the entire 8-bit char set is in use,  but
in fact I can't get anything the 7-bit ascii displayed correctly.

I've been digging around in "man xterm" and the HOWTO  docs,  looking
for some clues, but I haven't found any. The funny thing is that this
looks like a degeneration. A year or two back, all of the linux boxen
that  I  used  seemed  to have fully functional 8-bit xterms.  Now it
seems that none of them do.

One thing that seems like a possibility is that I'm looking  at  this
data  across  a  ssh link.  I wonder if ssh somehow shoots down 8-bit
chars and forces 7-bit charsets on everything?  There doesn't seem to
be  any  mention  of  the  topic  in the ssh man page, and there's no
obvious reason that ssh would do such a thing.

Anyhow, has anyone written any sort of guideline on how to make 8-bit
chars work and keep them working even across ssh and telnet links?

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).