RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1701605 - glibc: The locale command returns a vague error message if the LOCPATH environment variable is defined.
Summary: glibc: The locale command returns a vague error message if the LOCPATH enviro...
Keywords:
Status: CLOSED ERRATA
Alias: None
Deadline: 2019-05-22
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.1
Assignee: Arjun Shankar
QA Contact: qe-baseos-tools-bugs
Abhimanyu Jamaiyar
URL:
Whiteboard:
Depends On: 1717492
Blocks: 1684553
TreeView+ depends on / blocked
 
Reported: 2019-04-19 20:30 UTC by Greg Scott
Modified: 2023-07-18 14:30 UTC (History)
10 users (show)

Fixed In Version: glibc-2.28-57.el8
Doc Type: Bug Fix
Doc Text:
.The `locale` command now warns about `LOCPATH` being set whenever it encounters an error during execution Previously, the `locale` command did not provide any diagnostics for the `LOCPATH` environment variable when it encountered errors due to an invalid `LOCPATH`. The `locale` command is now set to warn that `LOCPATH` has been set any time it encounters an error during execution. As a result, `locale` now reports `LOCPATH` along with any underlying errors that it encounters.
Clone Of:
: 1717492 (view as bug list)
Environment:
Last Closed: 2019-11-05 21:29:04 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3513 0 None None None 2019-11-05 21:29:24 UTC
Sourceware 24478 0 P3 NEW Behavior of LOCPATH regarding archive and split-out locales is inconsistent 2020-03-17 19:50:41 UTC

Description Greg Scott 2019-04-19 20:30:02 UTC
Description of problem:
The locale command returns a vague error message if the LOCPATH environment variable is defined.

[root@rhel75test gregs]# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
.
.
.

This seems to be a legacy from AIX. See additional info below for more details.

Version-Release number of selected component (if applicable):
RHEL 6.all, 7.all, likely 8.n

How reproducible:
At will

Steps to Reproduce:
1. unset LOCPATH and the locale command works as advertised.
2. export LOCPATH=/any/path/anywhere and the locale command returns vague "No such file or directory" errors.
3.

Actual results:
The locale command returns errors when the LOCPATH environment variable is defined.

Expected results:
The locale command should return a useful error message if it has a problem; or it should not depend on the LOCPATH environment variable. If it needs to depend on the LOCPATH environment variable, it should be officially documented.

Additional info:

Here is how to reproduce the problem. As long as LOCPATH is undefined, local works as advertised. 

[root@rhel75test gregs]# unset LOCPATH
[root@rhel75test gregs]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[root@rhel75test gregs]# export LOCPATH=/home/garbage
[root@rhel75test gregs]# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[root@rhel75test gregs]#

Comment 2 Kamil Dudka 2019-04-19 22:17:55 UTC
The locale command is provided by glibc, not bash.

Comment 3 Greg Scott 2019-04-22 18:21:57 UTC
The customer who reported this wanted me to add this comments:

"Could you please also indicate in the Bugzilla that this problem also exists in RHEL6 ?  Or at least mention that it goes back to at least glibc-common-2.12-1.212.  I'm sure this problem is much, much older, but that's the oldest one I have."

I reproduced the problem myself with RHEL 6.10.

- Greg

Comment 4 Florian Weimer 2019-04-23 11:43:28 UTC
Note to anyone trying to reproduce this on current glibc versions: If LOCPATH is a non-existing path, the locale archive is ignored, but not split-out locale files from the glibc-langpack-* packages.

Perhaps the search order should be LOCPATH, archive, split-out locale files?

I'm not sure we can do much about detecting invalid LOCPATH settings in the locale tool.  If we change the search order, the error message would be gone in many cases, even if with an invalid LOCPATH setting.

Comment 5 Florian Weimer 2019-04-23 15:18:27 UTC
I posted a patch upstream with additional diagnostics:

https://sourceware.org/ml/libc-alpha/2019-04/msg00502.html

Comment 6 Florian Weimer 2019-04-23 16:19:33 UTC
New diagnostics are now upstream:

commit e485b2b6e006a7efa5d73e6be7e357a395c77fe3
Author: Florian Weimer <fweimer>
Date:   Tue Apr 23 18:16:26 2019 +0200

    locale: Add LOCPATH diagnostics to the locale program
    
    The implementation of quote_string is based on support_quote_blob.
    
    Reviewed-by: Carlos O'Donell <carlos>

Comment 7 Florian Weimer 2019-04-30 16:24:08 UTC
We do not plan to address issue in Red Hat Enterprise Linux 7, but will consider backporting the upstream diagnostic into Red Hat Enterprise Linux 8.

Comment 9 Florian Weimer 2019-05-22 07:57:00 UTC
The test case was fixed upstream with:

commit 439bf53496d6ed5fcef1d2e71793b46369f8205f
Author: Florian Weimer <fweimer>
Date:   Wed Apr 24 07:31:29 2019 +0200

    locale/tst-locale-locpath: Run test only for $(run-built-tests) == yes

Comment 10 Arjun Shankar 2019-05-22 15:50:31 UTC
Also included:

commit 439bf53496d6ed5fcef1d2e71793b46369f8205f
Author: Florian Weimer <fweimer>
Date:   Wed Apr 24 07:31:29 2019 +0200

    locale/tst-locale-locpath: Run test only for $(run-built-tests) == yes

thanks to Florian's review.

Comment 12 Sergey Kolosov 2019-09-03 12:44:12 UTC
Verified with locale/tst-locale-locpath

Comment 18 errata-xmlrpc 2019-11-05 21:29:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3513


Note You need to log in before you can comment on or make changes to this bug.