- linux-notes.org
- 2 thoughts on “ Настройка locate (локали) в Unix/Linux ”
- Добавить комментарий Отменить ответ
- Невозможно установить LC_CTYPE в качестве локали по умолчанию: нет такого файла или каталога
- 9 ответов
- Explain the effects of export LANG, LC_CTYPE, and LC_ALL [closed]
- 5 Answers 5
- Arch Linux
- #1 2020-03-04 21:04:29
- tmux: invalid LC_ALL, LC_CTYPE or LANG
- #2 2020-03-04 21:43:48
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #3 2020-03-04 22:57:48
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #4 2020-03-04 23:00:55
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #5 2020-03-04 23:20:19
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #6 2020-03-04 23:35:43
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #7 2020-03-05 19:18:19
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #8 2020-03-05 19:23:07
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- #9 2020-03-05 21:38:17
- Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
- Locale (Русский)
- Contents
- Генерирование локалей
- Установка локали
- Установка системной локали
- Переопределение системной локали в пользовательском сеансе
- Немедленное применение изменений локали
- Дополнительно
- Переменные окружения
- LANG: локаль по умолчанию
- LANGUAGE: запасные локали
- LC_TIME: формат даты и времени
- LC_COLLATE: порядок сортировки
- LC_ALL: решение проблем
- Советы и рекомендации
- Запуск приложения с другой локалью в терминале
- Запуск приложения с другой локалью из меню
- Решение проблем
- Эмулятор терминала не поддерживает UTF-8
- gnome-terminal или rxvt-unicode не поддерживают UTF-8
- Моя система использует неверный язык
linux-notes.org
Я получил сообщение об ошибке следующего содержания при подключении к любому удаленному Unix/Linux серверу терминал:
Сейчас, я расскажу в своей статье «Настройка locate (локали) в Unix/Linux» как можно данную ошибку исправить.
Смотрим какое переменное окружение установлено:
Можно отгрепать нужное:
Данная команда покажет на экран нужную локаль. Например, для кодировки UTF-8 нужна следующая локаль — ru_RU.utf8. При выводе данной команды если имеется данная локаль, нужно сейчас создать:
И добавляем в файл:
Для utf-8 используйте:
Сохраняем открытый файл и перезаходим в консоль, должен появиться русский шрифт в локали. Но бывает так, что при выводе команды:
Способ 1.
Ничего не показало ( нет именно русской локали), то мы сейчас это исправим:
И так, команда что выше, берет из директории /usr/share/i18n/locales/ файл с русской локалью с названием — ru_RU, а так же, из директории /usr/share/i18n/charmaps файлик с символьной картой для юникода с названием — UTF-8.gz. После чего, на основании двух этих файлов — генерирует необходимую локаль с именем — ru_RU.UTF-8. Собственно, локаль была сгенерирована, сейчас нужно выполнить все действия что я приводил выше.
Более расширенный вариант:
Способ 2.
Можно предотвратить передачу LC_* переменных в самой утилите (OpenSSH клиенте) на Unix/Linux машине.
Откройте /etc/ssh/ssh_config или /etc/ssh_config:
Удаляем или закоментируйте строку:
Сохраняйте и закройте данный файл. Настройка locate (локали) в Unix/Linux завершена.
2 thoughts on “ Настройка locate (локали) в Unix/Linux ”
Есть ли такая же статья по том как передать локали (напр. ru_RU) в питоновский докерфайл?
Просто в Dockerfile вставить:
ENV LANG=»ru_RU.UTF-8″
Так же, можно добавлять и другие переменные (LC_ALL, LC_CTYPE и так далее).
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Источник
Невозможно установить LC_CTYPE в качестве локали по умолчанию: нет такого файла или каталога
У меня есть точный вопрос как это, но нет никакого решения. Я пытался, но это не работает
Это из-за несовпадения en_US.UTF-8 и en_US.utf8?
9 ответов
Откройте терминал и выполните следующую команду:
Та же самая проблема (LC_CTYPE=UTF-8, что неправильно) может возникнуть, когда вы входите через ssh с Mac в Linux, и ваш терминал автоматически устанавливает переменные окружения. Для этого есть флажок. Снимите флажок, и вы готовы идти. В iTerm это находится в профиле-> вкладка терминала.
У меня была похожая проблема, и я добавил следующие строки в свой /etc/default/locale файл:
Только с этой работой для меня
Выход из locale Команда указывает, что у вас есть эта неправильная строка в вашей среде:
(«UTF-8» не является допустимым именем локали.)
Это обычно происходит от /etc/default/locale , Пожалуйста, удалите эту строку, если она есть, и перезапустите.
Если это не происходит оттуда, это может произойти из конфигурации вашей оболочки, или если вы вошли в систему удаленно через SSH, из конфигурации клиентского компьютера.
Эти команды спасли мою жизнь
Файл /etc/default/locale может иметь дополнительные (но ненужные) строки: Файл примера может выглядеть следующим образом:
Чтобы разобраться и успешно создать и перенастроить языковые стандарты, удалите или закомментируйте все строки из этого файла, кроме:
Файл должен наконец выглядеть так:
После этого беги dpkg-reconfigure locales выберите en_US.UTF-8, когда будет предложено выбрать локаль, и вы должны быть готовы. Вы получите Generation complete. сообщение, когда процесс завершен.
Мне удалось вызвать это самостоятельно при переносе файлов домашних каталогов на новый компьютер, и я некоторое время не мог определить причину из-за поиска файлов для LC_ но нет LOC ,
/.bashrc Файл, который я скопировал, имел следующее:
(Особое значение здесь было из-за предыдущих экспериментов с GNU Guix на старой машине; но релевантным фактом является просто то, что для переменной среды был задан недопустимый путь.)
Это приводило к следующей ошибке при запуске различных программ:
И эти ошибки при запуске locale :
Удаление (или комментирование) LOCPATH линия разрешила мои проблемы.
После того, как я попробовал все, что угодно, чтобы исправить это, я наконец понял — что, если проблема была на другой стороне scp? Видите ли, я испытывал это, когда пытался скопировать файл на свой сервер в облаке. Оба работают под управлением Ubuntu. Теперь я попробовал все вышеперечисленное, например, установить LC_ALL, локаль и т. Д., Но ничего не помогло. Я исправил это только после того, как меня осенило делать подобные вещи на стороне сервера.
Итак, я подключился к своему серверу и запустил:
И теперь, когда я перехожу со своего рабочего стола дома на свой сервер в облаке, я больше не вижу ошибок этого языка.
Источник
Explain the effects of export LANG, LC_CTYPE, and LC_ALL [closed]
Want to improve this question? Update the question so it’s on-topic for Stack Overflow.
Closed last year .
I’ve just installed Linux Mint 17 and faced a problem that I couldn’t use the Russian language in the terminal. (I see ? instead of letters.)
On one forum I found this solution:
It helped, but also changed my interface language to Russian (which I didn’t want). That’s not even a problem, but anyway, I would like to know, how this code works (every line).
5 Answers 5
I’ll explain with detail:
That is a shell command that will export an environment variable named LANG with the given value ru_RU.UTF-8 . That instructs internationalized programs to use the Russian language ( ru ), variant from Russia ( RU ), and the UTF-8 encoding for console output.
Generally this single line is enough.
Does a similar thing, but it tells the program not to change the language, but only the CTYPE to Russian. If a program can change a text to uppercase, then it will use the Russian rules to do so, even though the text itself may be in English.
It is worth saying that mixing LANG and LC_CTYPE can give unexpected results, because few people do that, so it is quite untested, unless maybe:
That will make the program output in Russian, but the CTYPE standard old C style.
The last line, LC_ALL is a last resort override, that will make the program ignore all the other LC_* variables and use this. I think that you should never write it in a profile line, but use it to run a program in a given language. For example, if you want to write a bug report, and you don’t want any kind of localized output, and you don’t know which LC_* variables are set:
About changing the language of all your programs or only the console, that depends on where you put these lines. I put mine in
/.bashrc so they don’t apply to the GUI, only to the bash consoles.
See at the Environment Variables of UNIX Specification page:
LANG This variable determines the locale category for native language, local customs and coded character set in the absence of the LC_ALL and other LC_* ( LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so forth.
LC_ALL This variable determines the values for all locale categories. The value of the LC_ALL environment variable has precedence over any of the other environment variables starting with LC_ (LC_COLLATE, LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) and the LANG environment variable.
LC_CTYPE This variable determines the locale category for character handling functions, such as tolower() , toupper() and isalpha() . This environment variable determines the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters), the classification of characters (for example, alpha, digit, graph) and the behaviour of character classes. Additional semantics of this variable, if any, are implementation-dependent.
export is confusing. It really means mark-for-export .
It implies child processes will later be created, and that’s when the actual exporting will be done.
The export order of events is: 1-ASSIGN, MARK, and . 2-FORK.
1) Create a new local shell variable, assign the value to it, and mark this variable for later export.
2) Then if and when, the current shell script is FORKED, (i.e. to create and run any child-processes), then start a child process with a COPY of this exported variable, as one of it’s many environment variables.
nb (note well): Not until step 2, and possibly long after the export declaration was issued, does the variable actually get exported. So: export only marks LANG. It does not export LANG.
By convention, exported variables are named in upper case.
Because LANG is only a copy, if the child later modifies this variable, it only modifies it for itself. The parent doesn’t see the child’s modifications.
Note that there are also many other environment variables passed to child processes from parent processes. These include all of the other environment variables that the parent process also gets from it’s parent.
So the child inherits all of the parent’s environment variables,
+ any additional ones that the parent marks for export ,
— less any variables which are explicitly unset .
In other words, we have two processes to think about: the parent process and any future child process(es).
The process you’re running, in this case profile , is what we’re calling the ‘parent process’.
profile can spawn one or more child processes, like for example if one of the things you do in profile is to run a program. That program is then (normally) run as a child process of profile . (This is not true if the file is sourced in profile, using the . or source notation, where what is sourced runs in the same process as profile .)
So now let’s look at the effects of these three environment variables.
Источник
Arch Linux
You are not logged in.
#1 2020-03-04 21:04:29
tmux: invalid LC_ALL, LC_CTYPE or LANG
I have an AWS EC2 instance running Arch Linux. When I installed tmux and tried to launch it from SSH, it prints that message.
Thanks, any help is appreciated. Also if you need any additional information please let me know
Last edited by ChingDim (2020-03-04 21:05:27)
#2 2020-03-04 21:43:48
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
#3 2020-03-04 22:57:48
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
I tried that before multiple times but obviously that didn’t work.
#4 2020-03-04 23:00:55
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
«locale -a» says there’s only POSX and C, so whatever you «tried», you either didn’t uncomment the proper (or any) locale or forgot to run locale-gen or ran the latter as regular user or …
Please decribe exactly what you «tried»: input, output and the contents of /etc/locale.gen
#5 2020-03-04 23:20:19
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
#6 2020-03-04 23:35:43
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
Please upload the actual /etc/locale.gen somewhere — the default contains every locale commented, so you must have edited a lot.
Maybe there’s some byte error (eg. idk. how it’d react to CRLF’s) and locale-gen omits all locales (according to that output)
Edit: shooting in all directions, «pacman -Qkk glibc; stat /bin/sh»
Last edited by seth (2020-03-04 23:40:37)
#7 2020-03-05 19:18:19
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
Please upload the actual /etc/locale.gen somewhere — the default contains every locale commented, so you must have edited a lot.
Maybe there’s some byte error (eg. idk. how it’d react to CRLF’s) and locale-gen omits all locales (according to that output)
Edit: shooting in all directions, «pacman -Qkk glibc; stat /bin/sh»
I have a /etc/locale.gen.pacnew that contains what I believed to be the actual file: It has tons of locales in #.
#8 2020-03-05 19:23:07
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
Alright, it seems that using that file and uncommenting en_USUTF-8 actually generates the locale now. I can enter tmux. Thanks for pointing out that mistake!
#9 2020-03-05 21:38:17
Re: tmux: invalid LC_ALL, LC_CTYPE or LANG
Please always remember to mark resolved threads by editing your initial posts subject — so others will know that there’s no task left, but maybe a solution to find.
Thanks.
If you still have the original file and want an opinion on why it might have failed, feel free to post it (but it must be the actual file, not a copy of its contents)
Источник
Locale (Русский)
Локали определяют язык, который использует система, а также региональные особенности, такие как денежные знаки, формат чисел, даты и времени и наборы символов. Они используются glibc и некоторыми другими программами или библиотеками для рендеринга текста.
Contents
Генерирование локалей
Имена локалей обычно имеют вид [язык][_ТЕРРИТОРИЯ][.НАБОР_СИМВОЛОВ][@модификатор] , где язык это код языка ISO 639, ТЕРРИТОРИЯ это код страны ISO 3166 и НАБОР_СИМВОЛОВ это кодировка вроде ISO-8859-1 или UTF-8. Смотрите setlocale(3) .
Чтобы вывести список всех доступных и сгенерированных локалей, выполните:
Перед тем, как локаль сможет быть использована в системе, она должна быть сгенерирована. Локали, которые вы можете сгенерировать перечислены в файле /etc/locale.gen . Чтобы сгенерировать локаль, первым делом раскомментируйте соответствующую строку в файле (а для удаления наоборот, закомментируйте); вы можете раскомментировать несколько локалей, в зависимости от ваших потребностей.
Например, для русской локали раскомментируйте ru_RU.UTF-8 UTF-8 :
После сохранения файла сгенерируйте выбранные локали командой:
Установка локали
Чтобы отобразить текущую локаль и связанные с ней переменные окружения, наберите:
Используемая локаль, выбранная среди сгенерированных в системе, устанавливается в файлах locale.conf , каждый из которых должен содержать список переменных окружения в том же формате, в каком их выводит команда locale.
Чтобы посмотреть список доступных ранее сгенерированных локалей, выполните:
Также можно использовать localectl(1) :
Установка системной локали
- Системная локаль устанавливается с помощью переменной LANG в файле /etc/locale.conf . Значением должен быть первый столбец из раскомментированной записи в /etc/locale.gen :
Вы можете установить ее также при помощи localectl:
Переопределение системной локали в пользовательском сеансе
- Системная локаль может переопределяться в каждом пользовательском сеансе с помощью файла
/.config/locale.conf (или, в общем случае, $XDG_CONFIG_HOME/locale.conf либо $HOME/.config/locale.conf ).
Немедленное применение изменений локали
После внесения изменений в файлы locale.conf , они вступят в силу после перезагрузки системы, и для отдельных сеансов пользователей — при входе. Чтобы принудительно обновить локаль в текущем окружении без перезагрузки, выполните:
Дополнительно
Переменные окружения настроек локали могут также быть установлены обычным способом, как указано на странице переменные окружения.
Например, чтобы проверить, как работает конкретное приложение с какой-нибудь локалью, вы можете запустить его следующим образом:
Аналогично, для установки локали всем процессам, запускаемом из текущей командной оболочки (например, в процессе установки системы):
Переменные окружения
Файлы locale.conf могут содержать следующие переменные окружения:
Полное объяснение этих переменных можно узнать в locale(7) , детали описаны в locale(5) .
LANG: локаль по умолчанию
Локаль, установленная в этой переменной используется в качестве значения для всех остальных LC_* -переменных, которые не установлены явно.
LANGUAGE: запасные локали
Программы, использующие gettext для перевода, учитывают также переменную LANGUAGE в дополнение к стандартным переменным. Это позволяет пользователям установить список локалей, которые будут использоваться в указанном порядке для поиска перевода. Если перевод для более предпочтительной локали (которая идет первее в списке) недоступен, будет произведена попытка получить перевод для следующей, и так далее. Например, пользователь из Австралии может предпочесть британский вариант перевода американскому:
LC_TIME: формат даты и времени
Например, если переменная LC_TIME имеет значение en_US.UTF-8 , будет использован формат даты ММ/ДД/ГГГГ . Если вы хотите использовать формат ISO 8601 ( ГГГГ-ММ-ДД ), установите:
LC_COLLATE: порядок сортировки
Эта переменная отвечает за правила определения сравнения наборов символов, которые используются для сортировки и регулярных выражений.
Установка значения LC_COLLATE=C , например, приведет к тому, что команда ls будет располагать файлы, имена которых начинаются с точки, первыми, за ними последуют имена, начинающиеся с цифры, затем с заглавной и, наконец, со строчной буквы:
Чтобы избежать возможных проблем, в Arch переменная установлена как LC_COLLATE=C в /etc/profile , однако этот метод сейчас устарел.
LC_ALL: решение проблем
Переменная LC_ALL переопределяет своим значением все LC_* -переменные, включая LANG , независимо от того, установлены они или нет.
Переменная LC_ALL — единственная из всех LC_ -переменных, которую нельзя установить в /etc/locale.conf : она предназначена только в целях проверки при решении проблем.
Советы и рекомендации
Запуск приложения с другой локалью в терминале
Например, чтобы запустить программу abiword на иврите:
Запуск приложения с другой локалью из меню
Скопируйте файл .desktop в домашний каталог пользователя:
И отредактируйте команду в опции Exec :
Решение проблем
Эмулятор терминала не поддерживает UTF-8
Небольшой список терминалов с поддержкой UTF-8:
- gnustep-terminal
- konsole
- mlterm
- rxvt-unicode (Русский)
- st
- эмуляторы на основе VTE
- xterm — необходимо запускать с опцией -u8 или с настройкой xterm*utf8: 2 . Также вы можете запускать uxterm, который предоставляется пакетом xterm .
gnome-terminal или rxvt-unicode не поддерживают UTF-8
Чтобы заработала поддержка UTF-8 в этих приложениях, необходимо запускать их с локалью, в которой установлена кодировка UTF-8, например ru_RU.UTF-8 . Включите эту локаль в системе, установите ее как системную локаль по умолчанию в соответствиями с инструкциями в предыдущих разделах и перезагрузите компьютер.
Моя система использует неверный язык
Возможно, некоторые переменные окружения из locale.conf были переопределены каким-то другим файлом, например
/.pam_environment , который используется в GNOME. Подробнее смотрите на странице Переменные окружения#Установка переменных.
Если вы используете окружение рабочего стола, такое как GNOME, его настройки могут перекрывать locale.conf .
KDE Plasma также позволяет изменить язык интерфейса через свои настройки. Если он всё равно использует язык по умолчанию после изменения, удаление файла
/.config/plasma-locale-settings.sh ) должно помочь.
Если вы используете экранный менеджер вместе с accountsservice , смотрите Display manager (Русский)#Установка языка.
LightDM автоматически использует accountsservice для выбора локали, если он установлен. В противном случае LightDM читает настройки сеанса из
/.dmrc . Возможно, что нежелательные настройки локали прочитались оттуда.
Источник