Thread: C locale sort in src/tools/make_ctags
Greetings, Attached is a simple one-liner for src/tools/make_ctags. If tags are sorted in locale other than C, vim complains: E432: Tags file not sorted: tags Solution is to set LANG variable to C before calling sort. Regards, Nicolai Tufar
Attachment
Nicolai Tufar wrote: > Greetings, > > Attached is a simple one-liner for src/tools/make_ctags. > If tags are sorted in locale other than C, vim complains: > > E432: Tags file not sorted: tags > > Solution is to set LANG variable to C before calling sort. That should be LC_ALL.
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > Nicolai Tufar wrote: > > Greetings, > > > > Attached is a simple one-liner for src/tools/make_ctags. > > If tags are sorted in locale other than C, vim complains: > > > > E432: Tags file not sorted: tags > > > > Solution is to set LANG variable to C before calling sort. > > That should be LC_ALL. Sounds fair. Both could be done. It worked for me just with LANG. Should I submit a new patch?
Nicolai Tufar wrote: > > -----Original Message----- > > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > > > Nicolai Tufar wrote: > > > Greetings, > > > > > > Attached is a simple one-liner for src/tools/make_ctags. > > > If tags are sorted in locale other than C, vim complains: > > > > > > E432: Tags file not sorted: tags > > > > > > Solution is to set LANG variable to C before calling sort. > > > > That should be LC_ALL. > > Sounds fair. Both could be done. It worked for me just with LANG. > Should I submit a new patch? Patch applied to do both. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/tools/make_ctags =================================================================== RCS file: /cvsroot/pgsql-server/src/tools/make_ctags,v retrieving revision 1.7 diff -c -c -r1.7 make_ctags *** src/tools/make_ctags 18 Jan 2003 06:06:51 -0000 1.7 --- src/tools/make_ctags 1 Feb 2004 23:10:42 -0000 *************** *** 10,15 **** --- 10,17 ---- find `pwd`/ \( -name _deadcode -a -prune \) -o \ -type f -name '*.[chyl]' -print|xargs ctags "$FLAGS" -a -f tags + LANG=C + LC_ALL=C sort tags >/tmp/$$ && mv /tmp/$$ tags find . -name 'CVS' -prune -o -type d -print |while read DIR
Bruce Momjian wrote: > Nicolai Tufar wrote: > > > -----Original Message----- > > > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > > > > > Nicolai Tufar wrote: > > > > Greetings, > > > > > > > > Attached is a simple one-liner for src/tools/make_ctags. > > > > If tags are sorted in locale other than C, vim complains: > > > > > > > > E432: Tags file not sorted: tags > > > > > > > > Solution is to set LANG variable to C before calling sort. > > > > > > That should be LC_ALL. > > > > Sounds fair. Both could be done. It worked for me just with LANG. > > Should I submit a new patch? > > Patch applied to do both. Thanks. LC_ALL overrides LANG, so please just one.
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > LC_ALL overrides LANG, so please just one. Don't do it! I just tried it with only LC_ALL and it did not work. Same "tags file is not sorted" error message from vi. Maybe sort does not honor LC_* variables, or something. My system is linux fedora core 1, by the way. Better leave both of them in place. Regards, Nicolai Tufar
Nicolai Tufar wrote: > > -----Original Message----- > > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > > > LC_ALL overrides LANG, so please just one. > > Don't do it! I just tried it with only LC_ALL and it did not > work. Same "tags file is not sorted" error message from vi. On second look, the patch is completely wrong anyway, because it does not export the variables; it depends on the user having exported them beforehand. The correct answer is to remove the LANG assignment and add LC_ALL=C export LC_ALL instead.
Peter Eisentraut <peter_e@gmx.net> writes:
> Nicolai Tufar wrote:
>> Don't do it! I just tried it with only LC_ALL and it did not
>> work. Same "tags file is not sorted" error message from vi.
> On second look, the patch is completely wrong anyway, because it does
> not export the variables; it depends on the user having exported them
> beforehand.
I saw that, but it seemed a non-problem to me: if the variables have not
been exported then they won't affect the sort program anyway.
I tried to reproduce Nicolai's statement about LC_ALL not being
sufficient, but AFAICT Fedora Core 1 handles this as expected:
$ cat /etc/redhat-release
Fedora Core release 1 (Yarrow)
$ LANG=en_US LC_ALL=en_GB locale
LANG=en_US
LC_CTYPE="en_GB"
LC_NUMERIC="en_GB"
LC_TIME="en_GB"
LC_COLLATE="en_GB"
LC_MONETARY="en_GB"
LC_MESSAGES="en_GB"
LC_PAPER="en_GB"
LC_NAME="en_GB"
LC_ADDRESS="en_GB"
LC_TELEPHONE="en_GB"
LC_MEASUREMENT="en_GB"
LC_IDENTIFICATION="en_GB"
LC_ALL=en_GB
$ cat zzz
abc DEF
ABC DEF
$ LANG=C sort zzz
ABC DEF
abc DEF
$ LANG=en_US sort zzz
abc DEF
ABC DEF
$ LANG=en_US LC_ALL=C sort zzz
ABC DEF
abc DEF
What I suspect is that Nicolai's environment supplies an explicit value
for LC_COLLATE, overriding both LC_ALL and LANG. If we want to be
bulletproof against that, then none of the proposals in this thread are
correct, and the correct patch is
+ LC_COLLATE=C
+ export LC_COLLATE
regards, tom lane
Tom Lane wrote: > I saw that, but it seemed a non-problem to me: if the variables have > not been exported then they won't affect the sort program anyway. He probably had LANG, but not LC_ALL, already exported in his environment. So when the shell program writes: LC_ALL=C then sort doesn't see it, because it is not exported, but LANG is still exported with the value he doesn't want. The solution is to export LC_ALL. > I tried to reproduce Nicolai's statement about LC_ALL not being > sufficient, but AFAICT Fedora Core 1 handles this as expected: > > $ cat /etc/redhat-release > Fedora Core release 1 (Yarrow) > $ LANG=en_US LC_ALL=en_GB locale You have both LC_ALL and LANG exported. > What I suspect is that Nicolai's environment supplies an explicit > value for LC_COLLATE, overriding both LC_ALL and LANG. If we want to > be bulletproof against that, then none of the proposals in this > thread are correct, and the correct patch is That's not possible, because LC_ALL overrides everything.
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> I saw that, but it seemed a non-problem to me: if the variables have
>> not been exported then they won't affect the sort program anyway.
> He probably had LANG, but not LC_ALL, already exported in his
> environment.
Ah, right, that would explain it.
> That's not possible, because LC_ALL overrides everything.
I hadn't realized that, but you seem to be right. Okay, setting
LC_ALL correctly should be sufficient.
regards, tom lane
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> I saw that, but it seemed a non-problem to me: if the variables have
> >> not been exported then they won't affect the sort program anyway.
>
> > He probably had LANG, but not LC_ALL, already exported in his
> > environment.
>
> Ah, right, that would explain it.
>
> > That's not possible, because LC_ALL overrides everything.
>
> I hadn't realized that, but you seem to be right. Okay, setting
> LC_ALL correctly should be sufficient.
OK, new code is:
LC_ALL=C
export LC_ALL
sort tags >/tmp/$$ && mv /tmp/$$ tags
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Thanks to Peter Eisentraut, Bruce Momjian and Tom Lane.
With the second CVS commit by Bruce Momjian it works fine now.
Peter Eisentraut <peter_e@gmx.net> wrote:
> > On second look, the patch is completely wrong anyway, because it
does
> > not export the variables; it depends on the user having exported
them
> > beforehand.
I stand corrected.
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I saw that, but it seemed a non-problem to me: if the variables have
not
> been exported then they won't affect the sort program anyway.
[...]
> What I suspect is that Nicolai's environment supplies an explicit
value
> for LC_COLLATE, overriding both LC_ALL and LANG. If we want to be
> bulletproof against that, then none of the proposals in this thread
are
> correct, and the correct patch is
>
> + LC_COLLATE=C
> + export LC_COLLATE
In my environment everything but LANG is set to tr_TR:
$ locale
LANG=tr_TR
LC_CTYPE="tr_TR"
LC_NUMERIC="tr_TR"
LC_TIME="tr_TR"
LC_COLLATE="tr_TR"
LC_MONETARY="tr_TR"
LC_MESSAGES="tr_TR"
LC_PAPER="tr_TR"
LC_NAME="tr_TR"
LC_ADDRESS="tr_TR"
LC_TELEPHONE="tr_TR"
LC_MEASUREMENT="tr_TR"
LC_IDENTIFICATION="tr_TR"
LC_ALL=
$
Method you suggested:
LC_COLLATE=C
export LC_COLLATE
works fine too.
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>
> OK, new code is:
>
> LC_ALL=C
> export LC_ALL
> sort tags >/tmp/$$ && mv /tmp/$$ tags
It works as expected. Thanks a lot.
Best regards,
Nicolai Tufar