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 10:48:07 -0400, Owen Taylor wrote:
> Eduardo Pérez Ureta <eperez@it.uc3m.es> writes:
> > On 2002-08-17 09:10:24 -0400, Owen Taylor wrote:
> > > Russ Allbery <rra@stanford.edu> writes:
> > > > Eduardo Pérez Ureta <eperez@it.uc3m.es> writes:
> > > > > Sure, POSIX says so. But POSIX should follow International Standards
> > > > > instead American Standards.
> > > >
> > > > > I don't want my system following Standards that only apply to America.
> > > >
> > > > > POSIX should be corrected about that.
> > > >
> > > > The appropriate time to ask vendors to change is after POSIX has been
> > > > changed, I think. It's better to comply with POSIX than to diverge from
> > > > it even if the divergence seems to make more logical sense.
> > > >
> > > > When you take up this issue with the POSIX working group, you'll discover
> > > > that they had good reasons for standardizing the date format that they
> > > > did, and also have some ideas about how to transition to more standard
> > > > international dates (basically by having users use locales more than they
> > > > do now).
> > >
> > > And there are, in fact, numerous other ways that the C locale
> > > isn't fully functional; the two most obvious being:
> > >
> > > - The character set is ASCII. (So, many programs won't be
> > > able to display 'Eduardo Pérez Ureta'! :-)
> >
> > You are right. But, as the main pango programmer, you know that
> > there's a confusion between the terminal charset and the string encoding
> > charset. The program has to know in what charset the characters come and
> > in what charset the characters you should output. If you have the fonts
> > why can't you see accentuated Latin characters or Japanese text in the C
> > locale on a xterm.
>
> 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
Right?
> 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.
> 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?
Regards
Eduardo