[pacman-dev] [PATCH 15/15] makepkg: remove unnecessary use of sort(1)

[Allan McRae]

On 19/06/10 12:54, Andres P wrote:
> On Fri, Jun 18, 2010 at 9:37 PM, Allan McRae<allan at 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