[pacman-dev] pacman sorting incompatible with 'sort' command
pacman internal sorting on package names differ from the one implemented in linux 'sort' command. pacman treats '-' (hyphen) differently. Testcase: 1. Install i3 group. It will install i3-wm, i3lock and i3status 2. Check the following commands: --($:~)-- pacman -Qeq | grep i3 i3-wm i3lock i3status --($:~)-- pacman -Qeq | grep i3 | sort i3lock i3status i3-wm --($:~)-- pacman -Qeq | grep i3 | sort -c sort: -:2: disorder: i3lock
On 05/05/17 at 09:19am, Adesh Kumar wrote:
pacman internal sorting on package names differ from the one implemented in linux 'sort' command.
pacman treats '-' (hyphen) differently.
Testcase:
1. Install i3 group. It will install i3-wm, i3lock and i3status
2. Check the following commands:
--($:~)-- pacman -Qeq | grep i3 i3-wm i3lock i3status
--($:~)-- pacman -Qeq | grep i3 | sort i3lock i3status i3-wm
--($:~)-- pacman -Qeq | grep i3 | sort -c sort: -:2: disorder: i3lock
pacman sorts according to the C locale. Why does this matter though? I don't believe we make any promises about query output order at all, let alone that it will match `sort`. apg
Andrew Gregory <andrew.gregory.8@gmail.com> wrote:
On 05/05/17 at 09:19am, Adesh Kumar wrote:
pacman internal sorting on package names differ from the one implemented in linux 'sort' command.
pacman treats '-' (hyphen) differently.
Testcase:
1. Install i3 group. It will install i3-wm, i3lock and i3status
2. Check the following commands:
--($:~)-- pacman -Qeq | grep i3 i3-wm i3lock i3status
--($:~)-- pacman -Qeq | grep i3 | sort i3lock i3status i3-wm
--($:~)-- pacman -Qeq | grep i3 | sort -c sort: -:2: disorder: i3lock
pacman sorts according to the C locale. Why does this matter though? I don't believe we make any promises about query output order at all, let alone that it will match `sort`.
apg
Hi. Well there are no promises I'm aware of, as Andrew said, but if pacman sorts according to C locale, then you just have to tell `sort` to use that, too. It makes sense that the output is different with different locales after all and if the same locale is used, chances of matching output are higher. The only thing one could complain about is, that it isn't mentioned in the documentation that pacman always sorts according to C locale regardless of the systems locale... But I don't mind... PoC: $ pacman -Slq | grep '^i3' i3-wm i3blocks i3lock i3status $ pacman -Slq | grep '^i3' | LC_COLLATE=C sort i3-wm i3blocks i3lock i3status -- regards, brainpower
Maybe pacman should sort according to the current locale, it's all in glibc so it should be trivial to implement. Is there a technical reason for using the C locale or is it just a default? On Fri, May 5, 2017, 9:58 AM brainpower <brainpower@mailbox.org> wrote:
Andrew Gregory <andrew.gregory.8@gmail.com> wrote:
On 05/05/17 at 09:19am, Adesh Kumar wrote:
pacman internal sorting on package names differ from the one implemented in linux 'sort' command.
pacman treats '-' (hyphen) differently.
Testcase:
1. Install i3 group. It will install i3-wm, i3lock and i3status
2. Check the following commands:
--($:~)-- pacman -Qeq | grep i3 i3-wm i3lock i3status
--($:~)-- pacman -Qeq | grep i3 | sort i3lock i3status i3-wm
--($:~)-- pacman -Qeq | grep i3 | sort -c sort: -:2: disorder: i3lock
pacman sorts according to the C locale. Why does this matter though? I don't believe we make any promises about query output order at all, let alone that it will match `sort`.
apg
Hi.
Well there are no promises I'm aware of, as Andrew said, but if pacman sorts according to C locale, then you just have to tell `sort` to use that, too. It makes sense that the output is different with different locales after all and if the same locale is used, chances of matching output are higher.
The only thing one could complain about is, that it isn't mentioned in the documentation that pacman always sorts according to C locale regardless of the systems locale... But I don't mind...
PoC:
$ pacman -Slq | grep '^i3' i3-wm i3blocks i3lock i3status $ pacman -Slq | grep '^i3' | LC_COLLATE=C sort i3-wm i3blocks i3lock i3status
-- regards, brainpower
-- Signed, Kieran Colford
On Fri, May 5, 2017 at 4:06 PM, Kieran Colford <kieran@kcolford.com> wrote:
Maybe pacman should sort according to the current locale, it's all in glibc so it should be trivial to implement. Is there a technical reason for using the C locale or is it just a default?
Trying to pin down the impact of a call to setlocale(LC_ALL, NULL). This changes the behavior of the following functions: fprintf, fscanf, printf, scanf, snprintf, sscanf, vfprintf, vfscanf, vprintf, vscanf, vsnprintf, vsprintf, vsscanf, mblen, mbtowc, wctomb, mbstowcs, wcstombs, strtol, strtoll, strtoul, strtoull, strcoll, strftime, strxfrm, isalnum, isalpha, isblank, iscntrl, isgraph, islower, isprint, ispunct, isspace, isupper, tolower, toupper Accoring to POSIX, these have to be taken into account additionally: exec, isdigit, iswalnum, iswalpha, iswblank, iswcntrl, iswctype, iswdigit, iswgraph, iswlower, iswprint, iswpunct, iswspace, iswupper, iswxdigit, isxdigit, localeconv, nl_langinfo, setlocale, strerror, strfmon, strtod, towlower, towupper, wcscoll, wcstod, wcsxfrm I'm not sure how exec functions behave with regard to setlocale, I don't think it should have any affect and only receive whatever is in **environ. Then again, it's mentioned in [0]. cheers! mar77i [0] http://pubs.opengroup.org/onlinepubs/009695399/functions/setlocale.html
participants (5)
-
Adesh Kumar
-
Andrew Gregory
-
brainpower
-
Kieran Colford
-
Martin Kühne