This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc: standard date/time format patch [drifting OT]


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
set and encoding, then things work. If everthing 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.

> > 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.)

Regards,
                                        Owen


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]