This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc: standard date/time format patch [drifting OT]
On 2002-08-19 19:41:56 -0400, Owen Taylor wrote:
> Eduardo Pérez Ureta <eperez@it.uc3m.es> writes:
> > > > On 2002-08-17 09:10:24 -0400, Owen Taylor wrote:
> > > I guess what you are saying is that the terminal encoding can be
> > > different from the LC_CTYPE that the *terminal* process is running
> > > under.
> > >
> > > (Please don't think this is a question of fonts; it so happens that
> > > you can pick a single byte encoding for xterm by selecting the
> > > right XLFD, but this is completely an implementation detail and
> > > makes no sense with any less brain-dead font system.)
> > >
> > > Yes, this is occasionally useful ... the most common case where
> > > it is useful is when you telnet/ssh from one machine, to a different
> > > machine running with a different LC_CTYPE.
> > >
> > > So, we can have:
> > >
> > > Encoding for the terminal display != LC_CTYPE of terminal process
> >
> > You mean:
> > I have my xterms at iso-8859-1 but when I use English programs
> > LC_CTYPE is ASCII
>
> The information that your Xterm is running in iso-8859-1 is only
> encoded in the fact that the font you set for your Xterm
> happens to be a iso-8859-1 font. Xterm doesn't know this.
>
> (Your font might be called 'fixed' or '10x20' and still be
> a iso-8859-1 font)
>
> Programs running in the Xterm certainly don't know this.
>
> > > But that doesn't mean we can have:
> > >
> > > Encoding for the terminal display != LC_CTYPE of application
> >
> > Why not? The same reasoning applies.
> >
> > I don't get what's the purpose of LC_CTYPE.
>
> The LC_CTYPE locale category defines the character set and encoding
> that the program operates in. If everthings agrees on the character
The program can work in whatever character set wants, if always translate
input and output to the Encoding for the terminal display.
The program can use UTF-8 internally and communicate in iso-8859-1 with
the terminal, or can operate in iso-8859-1 and communicate in UTF-8 with
the terminal.
> set and encoding, then things work. If everything doesn't agree,
> things don't work.
>
> If the LC_CTYPE is 'C' or 'POSIX', implying ASCII for the character
> set, then the agreement is ASCII.
But the encoding for the terminal display is iso-8859-1 and the program has
iso-8859-1 strings. Why can't it output iso-8859-1 strings?
> > > If the application has some text to display: say, 'Eduardo Pérez Ureta',
> > > then it has to know:
> > >
> > > A) What encoding the text is in.
> > > B) What encoding it needs to be converted to for terminal display.
> > >
> > > A) is an application detail. For B), the application needs to look
> > > at LC_CTYPE. In the 'C' locale, the answer for this is 'ASCII',
> > > so the application simply has no way of display the 'é'.
> > But the terminal is iso-8859-1, not pure ASCII.
> >
> > So, Why the application looks at LC_CTYPE instead of the Encoding for
> > the terminal display (possibly an environment variable)?
> >
> > Or should LC_CTYPE be set to the Encoding for the terminal display?
>
> This is what is expected. (Actually, LC_CTYPE normally just is
> derived from the LANG environment variable. See the GNU libc docs
> for full details.)
Why LANG specifies the Encoding for the terminal display?
Shouldn't the terminal set the environment variable that tells the
application what's the terminal encoding?
Regards
Eduardo