Hide Forgot
Description of problem: In Pashto - locale ps_AF.utf8 doesn't work human readable sort. Version-Release number of selected component (if applicable): coreutils-8.4-44.el6.x86_64 glibc-common-2.12-1.192.el6.x86_64 How reproducible: LC_ALL=ps_AF.utf8 sort -k1h data-afcomma.txt Actual results: 1 1٫2T 1 1٫2G 1k 1٫2G 1٫2k 1G 1٫2k 1٫2M 1M 1٫2M 1٫2T 1 1٫2T 1k 1٫2G 1k 1M 1٫2M 1M 1G 1٫2k 1G 1T 1T 1T Additional info: :: [ LOG ] :: Detected decimal mark '٫' for locale ps_AF.utf8 :: [ PASS ] :: Decimal point have to be known. (Expected 0, got 0) :: [ FAIL ] :: LC_ALL=ps_AF.utf8 sort -k1h (Expected 0, got 1) :: [ FAIL ] :: LC_ALL=ps_AF.utf8 sort -k2h (Expected 0, got 1) :: [ FAIL ] :: LC_ALL=ps_AF.utf8 sort -k3h (Expected 0, got 1)
This is caused by the fact that ps_AF.utf8 locale uses a multi-byte character as decimal point. This is not yet supported by upstream (neither in Fedora): http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/sort.c?id=34d1aeaf#n1905 http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/sort.c?id=34d1aeaf#n4229 http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/sort.c?id=34d1aeaf#n4236 Unless we have a business case for this feature, it will not be fixed in RHEL. Note that we intentionally do not have a RHEL-6 clone for bug #1355780 (similar to this one) because it introduces a change in behavior. Implementing a fix for this bug would be even more risky.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.