On Thu, 2003-07-03 at 15:07, gregory mott wrote:
i fail to understand. i've used the same stock definitions:
# --- /usr/share/i18n/locales/g ---
# build with:
# localedef -i g -c g
what i had missed was localedef -f
now i've got it
___
Paul Eggert wrote:
gregory mott writes:
can you/anyone give me a clue?
You might try reading the GNU C library manual on locales.
http://www.gnu.org/manual/glibc-2.2.5/html_node/Locales.html
Sorry, I don't use Red Hat, so you'll need to consult a Red Hat expert
for details specific to
On Tue, 2003-07-01 at 23:18, Paul Eggert wrote:
gregory mott [EMAIL PROTECTED] writes:
can you point me to an appropriate RTFM that ideally would layout what
encodings are used by what locales, or how to tell what encoding you
have/need, etc usw?
Sorry, no; this stuff tends to be
gregory mott [EMAIL PROTECTED] writes:
when i pass textual input to sort, how does sort come to decide or infer
the encoding?
From the locale. It looks at the LC_ALL environment variable; if that
isn't set it looks at LC_CTYPE; if that isn't set it looks at LANG;
otherwise the default locale
gregory mott [EMAIL PROTECTED] writes:
for example, en_IN repeatably produces proper results, but en_AU
repeatably fails to handle some special characters properly.
I reproduced your results on my host (Debian GNU/Linux 3.0r1).
However, on my host what you were doing was a user error, as en_IN
gregory mott [EMAIL PROTECTED] writes:
can you point me to an appropriate RTFM that ideally would layout what
encodings are used by what locales, or how to tell what encoding you
have/need, etc usw?
Sorry, no; this stuff tends to be scattered around all over the place.
On my Debian GNU/Linux
On Tue, 2003-07-01 at 21:43, Paul Eggert wrote:
gregory mott [EMAIL PROTECTED] writes:
for example, en_IN repeatably produces proper results, but en_AU
repeatably fails to handle some special characters properly.
I reproduced your results on my host (Debian GNU/Linux 3.0r1).
However, on
it seems sort is suffering from some subtle bug. does this happen for
anyone else? is it just my machine, is it a redhat problem, or is it
actually a gnu bug?
for example, en_IN repeatably produces proper results, but en_AU
repeatably fails to handle some special characters properly. but both
