On 19/06/10 12:54, Andres P wrote:
On Fri, Jun 18, 2010 at 9:37 PM, Allan McRae<allan@archlinux.org> wrote:
On 19/06/10 09:51, Andres P wrote:
pacman -Qq output is always sorted!
No it is not... it depends on your locale whether the order is correct for inputting into comm.
You're wrong, pacman -Qq output *is* always sorted according to LC_COLLATE=C.
First I created a package called Kernel26, LC_COLLATE would put it untop since it gives priority to uppercase. en_US does not.
$ exec 1>/dev/null
$ LC_COLLATE=C comm<(LC_COLLATE=C pacman -Qq) \ <(LC_COLLATE=en_US.UTF-8 pacman -Qq)
No errors... but one you use a program that respects LC_COLLATE:
$ LC_COLLATE=C comm \ <(LC_COLLATE=C sort<<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort<<<$'a\nB\nc')
comm: file 2 is not in sorted order
$ LC_COLLATE=en_US.UTF-8 comm -3 \ <(LC_COLLATE=C sort<<<$'a\nB\nc') \ <(LC_COLLATE=en_US.UTF-8 sort<<<$'a\nB\nc') a comm: file 1 is not in sorted order
So you are saying that if your locale sorts in a different order that LC_COLLATE=C, then the order output by pacman is wrong for input into comm. Kind of like saying "it depends on your locale whether the order is correct for inputting into comm". Which is exactly what I said and you replied with "you're wrong". Interesting...
So the solution is: * Treat the pacman bug as what it is, a separate bug. Since it *does* sort, just to the wrong LC_COLLATE. This is much cleaner than forking sort(1).
* Or, simply change comm to LC_COLLATE=C and speed it up since this collation is always faster.
Pick one and fix it. Until then the sort stays. If you pick the second, then it would be best to write a bug report about the first. Allan