Homebrew-core: Failed to set locale category

[pkropachev]

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

• [x] are reporting a bug others will be able to reproduce and not asking a question or requesting software. If you're not sure or want to ask a question do so on our Discourse: https://discourse.brew.sh. To get software added or changed in Homebrew please file a Pull Request
• [ ] have a problem with brew install (or upgrade, reinstall) a single, Homebrew/homebrew-core formula (not cask) on macOS? If it's a general brew problem please file this issue at Homebrew/brew: https://github.com/Homebrew/brew/issues/new/choose. If it's a Linux problem please file this issue at https://github.com/Homebrew/linuxbrew-core/issues/new/choose. If it's a brew cask problem please file this issue at https://github.com/Homebrew/homebrew-cask/issues/new/choose. If it's a tap (e.g. Homebrew/homebrew-php) problem please file this issue at the tap.
• [x] ran brew update and can still reproduce the problem?
• [x] ran brew doctor, fixed all issues and can still reproduce the problem?
• [ ] ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link?
• [ ] if brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

brew doctor: Your system is ready to brew.
brew config:
HOMEBREW_VERSION: 2.1.6
ORIGIN: https://github.com/Homebrew/brew
HEAD: fddf5b16bd8df577380a1d810d17825ef611b81f
Last commit: 4 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 0bccc67d96ca2420cae0597f8b9712bb71e71397
Core tap last commit: 13 minutes ago
HOMEBREW_PREFIX: /usr/local
CPU: quad-core 64-bit ivybridge
Homebrew Ruby: 2.3.7 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 10.0 build 1001
Git: 2.22.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 11.0.3, 1.8.0_211, 1.7.0_80
macOS: 10.14.5-x86_64
CLT: 10.2.1.0.1.1554506761
Xcode: 10.2.1
CLT headers: 10.2.1.0.1.1554506761
XQuartz: 2.7.11 => /opt/X11

To help us debug your issue please explain:

• What you were trying to do (and why)

I run some utilities installed from homebrew (like vim, wget, mc).

• What happened (include command output)

Utilities are ran, but I get the following warnings before:

[pkropach@Pavels-MBP:~]$ wget
Warning: Failed to set locale category LC_NUMERIC to en_RU.
Warning: Failed to set locale category LC_TIME to en_RU.
Warning: Failed to set locale category LC_COLLATE to en_RU.
Warning: Failed to set locale category LC_MONETARY to en_RU.
Warning: Failed to set locale category LC_MESSAGES to en_RU.
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

[pkropach@Pavels-MBP:~]$ brew info vim
vim: stable 8.1.1550 (bottled), HEAD
Vi 'workalike' with many additional features
https://www.vim.org/
Conflicts with:
  ex-vi (because vim and ex-vi both install bin/ex and bin/view)
  macvim (because vim and macvim both install vi* binaries)
/usr/local/Cellar/vim/8.1.1550 (1,855 files, 31.6MB) *
  Poured from bottle on 2019-06-19 at 08:52:43
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/vim.rb
==> Dependencies
Required: gettext ✔, lua ✔, perl ✔, python ✔, ruby ✔
==> Options
--HEAD
    Install HEAD version
==> Analytics
install: 91,235 (30 days), 216,480 (90 days), 831,331 (365 days)
install_on_request: 84,085 (30 days), 199,020 (90 days), 743,222 (365 days)
build_error: 0 (30 days)

• What you expected to happen

No warnings should appear.

• Step-by-step reproduction instructions (by running brew install commands)

$ brew install vim
$ vim

[jonchang]

locale -a doesn't list en_RU as a valid locale; I think this is why you are seeing the errors. Setting your LC_* environment variables will likely fix the issue.

[pkropachev]

It's true. Currently my LC_* variables have the following values:

[pkropach@Pavels-MBP:~]$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

After change Region (from Russia to United States) the values of variables are the following:

[pkropach@Pavels-MBP:~]$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

And utilities are started without warnings.

[pkropach@Pavels-MBP:~]$ wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

But why did this happen? I didn't have such problem until the latest update.

And locale "C" is presented in list.

[pkropach@Pavels-MBP:~]$ locale -a | grep -E "^C$"
C

[jdijt]

I'm not sure if this is in brew or in OSX

e.g.:
My 'Language and Region' configuration used to be: Language: English, region: Netherlands. A configuration that according to OSX is valid and generally works: my mac speaks english and shows dates/currency/etc in the Dutch format. Now since a few days I get similar messages in the terminal, that I didn't get before.

Warning: Failed to set locale category LC_NUMERIC to en_NL.
Warning: Failed to set locale category LC_TIME to en_NL.
Warning: Failed to set locale category LC_COLLATE to en_NL.
Warning: Failed to set locale category LC_MONETARY to en_NL.
Warning: Failed to set locale category LC_MESSAGES to en_NL.

It wouldn't surprise me if these messages where always there, but something changed that made them visible.

I think switching region is not a proper solution -> Either OSX needs to generate the proper locale(s) when we select an otherwise valid setup. Or we should be able to silence the warning one way or the other.

[SMillerDev]

I guess that's dependent on the recent gettext update. https://savannah.gnu.org/forum/forum.php?forum_id=9430. You should probably use localedef to generate the locale you're using then. Either way it's not something Homebrew could fix, please file issues with Apple and/or gettext.

[pkropachev]

Currently I've just added export LC_ALL in my .bash_profile.

export LC_ALL=en_US.UTF-8

[fluff]

FWIW, I've started getting the same warnings complaining about a missing en_NO locale. How would one go about using localedef to quiet these errors? I have set LC_MESSAGES=en_US and LC_CTYPE=no_NO and the rest are set to C or blank. Maybe this is a regression in gettext 0.20, but it does seem like this would affect most Homebrew users in non-US regions with English display language.

[SMillerDev]

FWIW, I've started getting the same warnings complaining about a missing en_NO locale.

Yeah, that one probably doesn't exist in the output of locale -a either, meaning it's invalid.

How would one go about using localedef to quiet these errors?

man localedef

Maybe this is a regression in gettext 0.20, but it does seem like this would affect most Homebrew users in non-US regions with English display language.

It's a fix and it affects everyone who used a non-existant locale.

[fluff]

FWIW, I've started getting the same warnings complaining about a missing en_NO locale.

Yeah, that one probably doesn't exist in the output of locale -a either, meaning it's invalid.

Obviously, but nowhere in locale or env do I have an en_NO entry. So it looks like something in gettext 0.20 changed and constructed this weird combination on its own.

How would one go about using localedef to quiet these errors?

man localedef

Thanks, I tried that command but it didn't fix anything. ;)

Maybe this is a regression in gettext 0.20, but it does seem like this would affect most Homebrew users in non-US regions with English display language.

It's a fix and it affects everyone who used a non-existant locale.

See, I don't believe I am using a "non-existant locale". I don't have any env vars mentioning the locale combination en_NO, only no_NO or en_US. So my opinion is that this is a regression in the new version of gettext that for some reason decides to construct a weird en_NO setting for LC_NUMERIC where none is set, perhaps by interpreting the macOS system settings for regional settings in an incompatible way.

Anyways, I quieted these new warnings for now by exporting LANG=en_US in my shell.

[pkropachev]

From release notes for gettext 0.20:

The interpretation of the language preferences on macOS has been fixed.

Looks like gettext's team has fixed the oldest bug (gettext ignored locales which didn't exist in macOS). In fact, problem has been fixed, but this fix created headache for us.
So, now gettext gets the current system locale and if this locale doesn't exist then gettext prints warning in stderr.
Current system locale can be extracted by the following commands:

[pkropach@Pavels-MBP:~]$ defaults read -g AppleLocale
en_RU
[pkropach@Pavels-MBP:~]$ defaults read -g AppleLanguages
(
    "en-RU"
)

[pkropachev]

Actually, gettext's team has made improvement in the latest commit (see link).

2)
  - the warnings will only appear when the environment variable
    SETLOCALE_VERBOSE is set to a non-empty value - so that output to stderr
    is avoided by default.

if (warn)
{
                        /* Warn only if the environment variable
                           SETLOCALE_VERBOSE is set.  Otherwise these warnings
                           are just annoyances, since normal users won't invoke
                           'localedef'.  */
                        const char *verbose = getenv ("SETLOCALE_VERBOSE");
                        if (verbose != NULL && verbose[0] != '\0')
                          fprintf (stderr,
                                   "Warning: Failed to set locale category %s to %s.\n",
                                   category_to_name (cat), name);
}

So, I guess, the problem with warnings will be fixed in the next version of gettext, because SETLOCALE_VERBOSE variable is not set by default. Thus, waiting for new version of gettext...

[arvenil]

Same issue :/

➜  ~ defaults read -g AppleLocale
en_PL
➜  ~ defaults read -g AppleLanguages
(
    "en-GB"
)

[sandino]

I' just put

export LC_NUMERIC=en_US.UTF-8
export LC_TIME=en_US.UTF-8
export LC_COLLATE=en_US.UTF-8
export LC_MONETARY=en_US.UTF-8
export LC_MESSAGES=en_US.UTF-8

to my .zshrc