Red Hat Bugzilla – Full Text Bug Listing
|Summary:||sort -b --key 1.2,1.4M fails; sort --key 1.2b,1.4M works.|
|Product:||[Fedora] Fedora||Reporter:||archimerged Ark submedes <archimerged>|
|Component:||coreutils||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||kdudka, ovasik, redhat, twaugh|
|Fixed In Version:||6.12-20.fc10||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-27 22:22:03 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description archimerged Ark submedes 2009-02-16 10:16:27 EST
Description of problem: In sort(1), when using the M flag on a key, the global -b flag is ignored, and must be specified on the first POS of the key. Version-Release number of selected component (if applicable): coreutils-6.10-33.fc9.i386 How reproducible: every time Steps to Reproduce: $ printf -- '-Jan-\n -Mar-\n -Feb-\n' | sort -b --key 1.2,1.4M -Feb- -Mar- -Jan- $ printf -- '-Jan-\n -Mar-\n -Feb-\n' | sort --key 1.2b,1.4M -Jan- -Feb- -Mar- $ printf -- '-Jan-\n -Mar-\n -Feb-\n' | sort --key 1.2,1.4bM -Feb- -Mar- -Jan- $ printf -- 'a -Jan-\na -Mar-\na -Feb-\n' | sort -b --key 2.2,2.4M a -Feb- a -Jan- a -Mar- $ printf -- 'a -Jan-\na -Mar-\na -Feb-\n' | sort --key 2.2b,2.4M a -Jan- a -Feb- a -Mar- $ printf -- 'a -Jan-\na -Mar-\na -Feb-\n' | sort --key 2.3,2.5M a -Jan- a -Feb- a -Mar- $ Actual results: as shown Expected results: global -b should work the same as key suffix b. Additional info:
Comment 1 Ondrej Vasik 2009-02-25 10:39:43 EST
Thanks for report, problem actually solved this week by upstream (patch is here: http://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00258.html), fixed in rawhide, built as coreutils-7.1-3.fc11, will include the fix in next coreutils update for already releassed Fedoras.
Comment 2 Fedora Update System 2009-02-26 11:53:04 EST
coreutils-6.12-19.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/coreutils-6.12-19.fc10
Comment 3 Fedora Update System 2009-02-27 06:06:34 EST
coreutils-6.10-34.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/coreutils-6.10-34.fc9
Comment 4 Fedora Update System 2009-02-27 22:21:53 EST
coreutils-6.12-19.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Comment 5 David 2009-03-01 04:46:29 EST
Unless I am understanding the man page wrong, this update has caused a regression. Consider the file: 1 2 3 2 3 4 1 50 60 100 200 300 1033 1 2 102 200 300 If I run "sort -n -k 1,1" on it, before the update (and on an OpenSUSE machine right now) I got this: 1 2 3 1 50 60 2 3 4 100 200 300 102 200 300 1033 1 2 Now I get this, which does not really conform to any logical ordering: 100 200 300 102 200 300 1033 1 2 1 2 3 1 50 60 2 3 4 Also, now there are files that are really messed up when sorted using the above command, where the keys aren't even grouped together (e.g. successive lines might start with 994, 9, 995, 995, 9, 996, ...). I can post some test files if necessary.
Comment 6 Ondrej Vasik 2009-03-02 06:08:26 EST
It works correctly for C locales - which are recommended for reliable sort by info/man pages. With `LC_ALL=C sort -n -k1,1 test` I got correct results even with the updated sort. Problem seems to be in i18n patch (which never got upstream and is very unlikely to have it accepted by upstream unless someone will rewrite it from scratch) - and therefore in locales. Could you please provide locale which you use and confirm that the sort works correctly for C locale? If so, I will try to fix the i18n patch to make it work again as the sort should (mostly) work for non-C locales as well.
Comment 7 David 2009-03-02 06:53:29 EST
Is LANG what you're asking for? If so, it's en_US.UTF-8 on my machine. When I set LC_ALL=C, sort seems to be doing what I expect. However, I can't imagine it not being a bug for sort -n -k 1,1 to produce output like this: ... 999, 65, 6, 60, 3/9/2009 99, 97, 9, 13, 1/23/2009 999, 98, 2, 87, 11/1/2008 999, 98, 2, 87, 1/16/2009 ... It looks like it's kind-of-sort-of sorting by the second column as well as the first.
Comment 8 Ondrej Vasik 2009-03-02 07:50:00 EST
Thanks for quick response, LANG is enough... it is obviously bug in multibyte patch (i18n) - Upstream fix for buggy sort behaviour was fixing only unibyte section and I forgot to adjust multibyte section provided by i18n ... `LC_ALL=C sort` workaround should work for every case now, multibyte patch (i18n) fixed in rawhide and now building in koji as coreutils-7.1-6.fc11.
Comment 9 Fedora Update System 2009-03-02 09:25:57 EST
coreutils-6.12-20.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/coreutils-6.12-20.fc10
Comment 10 Fedora Update System 2009-03-16 15:42:13 EDT
coreutils-6.10-35.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2009-03-16 15:47:08 EDT
coreutils-6.12-20.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.