C locale sort in src/tools/make_ctags

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

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

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