кракозябры в консоли linux

Кодировка в консоли (Решено)

Здравствуйте.
Устанавливаю арч на ноутбук, вроде всё делаю по проторенной уже дорожке, но наверное раз на раз не приходится.
Создал файл:

Раскоментировал в файле locale.gen, строки

В locale.conf прописал:

Если для вашей видеокарты при загрузке системы подключается drm-модуль, например i915 для intel, его старт приводит к появлению нового устройства фреймбуфера (или замене старого на новый) (/dev/fb0 и т.д.), и повторной инициализации консоли со сбросом шрифта. Если это происходит уже после того, как systemd-vconsole-setup загрузила ваш шрифт, вам требуется либо загрузить его повторно, либо обеспечить старт drm-модуля заведомо раньше загрузки шрифта.

Вики русский
Суть уловил с исполнением пока туговато, будем понемногу разбираться. Спасибо за пояснение и способ решения.
Тема на форуме

ZeniaM
Суть уловил с исполнением пока туговато, будем понемногу разбираться. Спасибо за пояснение и способ решения.

Источник

Как я боролся с кодировками в консоли

В очередной раз запустив в Windows свой скрипт-информер для СамИздат-а и увидев в консоли «загадочные символы» я сказал себе: «Да уже сделай, наконец, себе нормальный кросс-платформенный логгинг!»

Об этом, и о том, как раскрасить вывод лога наподобие Django-вского в Win32 я попробую рассказать под хабра-катом _{(Всё ниженаписанное применимо к Python 2.x ветке)}

Задача первая. Корректный вывод текста в консоль

Симптомы

До тех пор, пока мы не вносим каких-либо «поправок» в проинициализировавшуюся систему ввода-вывода и используем только оператор print с unicode строками, всё идёт более-менее нормально вне зависимости от ОС.

«Чудеса» начинаются дальше — если мы поменяли какие-либо кодировки (см. чуть дальше) или воспользовались модулем logging для вывода на экран. Вроде бы настроив ожидаемое поведение в Linux, в Windows получаешь «мусор» в utf-8. Начинаешь править под Win — вылезает 1251 в консоли…

Теоретический экскурс

Ищем решение

Очевидно, чтобы избавиться от всех этих проблем, надо как-то привести их к единообразию.
И вот тут начинается самое интересное:

Кроме того, как замечательно видно из примера, если в linux у нас везде utf-8, то в Windows — две разных кодировки — так называемая ANSI, она же cp1251, используемая для графической части и OEM, она же cp866, для вывода текста в консоли. OEM кодировка пришла к нам со времён DOS-а и, теоретически, может быть также перенастроена специальными командами, но на практике никто этого давно не делает.

До недавнего времени я пользовался распространённым способом исправить эту неприятность:

… и собрать всё вместе:

Задача вторая. Раскрашиваем вывод

Попробовав несколько из них, я, в итоге, воспользовался простейшим наследником StreamHandler, приведённом в одном из комментов на Stack Overflow и пока вполне доволен:

Однако, в Windows всё это работать, разумеется, отказалось. И если раньше можно было «включить» поддержку ansi-кодов в консоли добавлением «магического» ansi.dll из проекта symfony куда-то в недра системных папок винды, то, начиная (кажется) с Windows 7 данная возможность окончательно «выпилена» из системы. Да и заставлять юзера копировать какую-то dll в системную папку тоже как-то «не кошерно».

Снова обращаемся к гуглу и, снова, получаем несколько вариантов решения. Все варианты так или иначе сводятся к подмене вывода ANSI escape-последовательностей вызовом WinAPI для управления атрибутами консоли.

Побродив некоторое время по ссылкам, набрёл на проект colorama. Он как-то понравился мне больше остального. К плюсам именно этого проекта ст́оит отнести, что подменяется весь консольный вывод — можно выводить раскрашенный текст простым print u»\x1b[31;40mЧто-то красное на чёрном\x1b[0m» если вдруг захочется поизвращаться.

Сразу замечу, что текущая версия 0.1.18 содержит досадный баг, ломающий вывод unicode строк. Но простейшее решение я привёл там же при создании issue.

Собственно осталось объединить оба пожелания и начать пользоваться вместо традиционных «костылей»:

Дальше в своём проекте, в запускаемом файле пользуемся:

На этом всё. Из потенциальных доработок осталось проверить работоспособность под win64 python и, возможно, добаботать ColoredHandler чтобы проверял себя на isatty, как в более сложных примерах на том же StackOverflow.

Источник

При этом
#service console-cyrillic отрабатывает с ошибкой
а
#service console-setup делает консоль русской.

Пробовал и
insserv console-setup
и
insserv console-cyrillic

И оба сразу и по отдельности.

При перезагрузке кириллица слетает до исполнения этих команд из консоли.

apt-get purge console-cyrillic

Не Помогло. После перезагрузки кракозябры.

dpkg-reconfigure console-setup
dpkg-reconfigure locales

В общем: /etc/profile добавил последней строкой:
/etc/init.d/console-setup start

P.S. Но отрабатывает только при логине root.
Обычный юзер попадает в кракозябры.

смотри в лог почему console-setup не грузится при загрузке ос

смотри в лог почему console-setup не грузится при загрузке ос

Как раз сейчас фотографировал экран чтобы сюда запостить.
systemd[1]: Job console-setup.service/start deleted to break ordering cycle starting with basic.target/start

у тебя там какой-то бардак в init.d организовался. интересно что вообще у тебя делал console-cyrillic в jessie, если это пакет костылей для sarge (2005 год)

детальнее, что происходит увидишь так:
/etc/default/grub
добавь в строку GRUB_CMDLINE_LINUX=«systemd.log_level=debug»
grub-update

после перезагрузки в journalctl будет детальный лог загрузки.

затем пройтись так:

Попробуй сделать файл /etc/vconsole.conf с содержимым:

В дебиане не собирают systemd-vconsole-setup, и костылик для udev тоже не кладут. Нечему читать этот файл, или я ошибаюсь?

В ошибках всё тот же: Job console-setup.service/start deleted to break ordering cycle

# grub-update
grub-update: command not found

# systemctl status console-setup service

да, его и запускать, перепутал местами слова

тут должна быть точка console-setup.service# systemctl status console-setup.service

Потому-что не смог запустится и процесс умер.
Все ответы в логах.

Потому-что не смог запустится и процесс умер.
Все ответы в логах.

Пойду курить логи, но:
«Job console-setup.service/start deleted to break ordering cycle
»

. Я же выше писал что не раз это делал.

Тебе перевести эту строчку или какой твой вопрос?

Я тебе уже ответил, это проблема сидит в /etc/init.d, что-то забыло там свой файл или сломало зависимости у существующих и выдал стандартное решение проблем с зависимостями и забытыми конфигами, плюс показал как увидеть загрузку в деталях.

Я тебе уже ответил, это проблема сидит в /etc/init.d, что-то забыло там свой файл или сломало зависимости у существующих и выдал стандартное решение проблем с зависимостями и забытыми конфигами, плюс показал как увидеть загрузку в деталях.

Спасибо за советы, буду курить,курить,курить. С ходу пока не понял.

Как бы по укурке не сломать систему.

например ^rc это удалённые, но не до конца, например оставили свои конфиги. можешь смело сносить те, которые тебе не понадобятся

вот тут надо конечно прибраться, но уже после чистки выше. впрочем можешь сразу обратить внимание на те, что лежат в /etc/init.d и прибраться там

забавно, как на одном сайтике тусуются кучи тех, кто знает всякую херню про кривонастроенный компоненты гнулинукса. вот уж система для десктопа

у тебя там какой-то бардак в init.d организовался. интересно что >вообще у тебя делал console-cyrillic в jessie, если это пакет костылей для sarge (2005 год)

Так поставил Jessie, кракозябры. Я поставил console-cyrillic присутствующий в дистрибутиве, сделал dpkg-reconfigure locales и dpkg-reconfigure console-cyrillic всё появилось и я успокоился. Пока сегодня в консоль не полез.
.
Впрочем я же по Вашему совету сделал ему purge и это не помогло.
Сейчас поставил его взад и он много чего писал и спрашивал по поводу знакогенератора при загрузке, но при загрузке так и не грузит знакогенератор.

Скорость реакции лучше чем у оффтопика. Несколько лет уже на десктопе юзаю.
Вот было бы: apt-get install 1c и всю страну можно бы было на Debian пересаживать (Исключая геймеров).

Это уже зависит от фирмы 1С, а не от сообщества Debian к сожалению. 1С пока даже не собирается выкладывать бинари в свободный доступ, не говоря уже о исходниках.

Я тебе уже ответил, это проблема сидит в /etc/init.d, что-то забыло там свой файл или сломало зависимости у существующих и выдал стандартное решение проблем с зависимостями и забытыми конфигами, плюс показал как увидеть загрузку в деталях.

Сломал я Линуксовый десктоп.

start буквы появились. осталось иксы поднять.
Сломал я Линуксовый десктоп.

Ага.
#apt-get install xorg

По дефолту (console-setup) всё прекрасно работает.
Никогда не ставь console-cyrillic. Просто запомни это правило. Если тебе придётся его
ставить, значит ты уже знаешь что он для расширенной поддержки кириллицы на основе русского алфавита для малоиспользуемых языков, напр удмуртского и тебе нужен удмуртский в консоли просто позарез.

Чего-то ты не договариваешь. Я тучу Jessie ставил, как на чистую, так и обновлением со Squeeze, если ставить с иксами, то всё из коробки работает, если же ставить с нетинстала минимальную систему, то потом достаточно поставить и настроить console-setup. console-cyrillic при этом совершенно не нужна.

Очевидно, к Демьяну подошел ты не с той стороны. Как писали выше, dpkg-reconfigure решает все вопросы с русификацией и шрифтами.

Источник

Как сменить locale в Debian или пишем кириллицей в консоли linux

Я знаю что кириллица в логах Linux – это самый страшный грех для айтишника, но иногда это просто необходимость. Одна из таких необходимостей возникает при создании централизованного хранения log-файлов различных операционных систем. Microsoft всегда в своих log`ах применяет кириллицу и поэтому если мы хотим получать log-файлы и от Win-серверов, то стоит смириться, что в log`ах будет кирилица.

Для того, чтобы эти логи нормально отображались нам и нужно явно указать locale в Debian, Ubuntu или какой Linux-дистрибутив Вы используете.

Чтобы добавить кириллицу, чтобы Linux сервер нормально отображал русские буквы, нужно объяснить ему, что необходимо работать в той же кодировке, что и Windows.

Для того, чтобы управлять локалью в Linux, необходим пакет locales, который должен быть у Вас установлен. В большинстве случаев пакет locales уже будет у Вас установлен, поэтому для проформы просто проверяем этот факт.

Посмотреть установленную locale linux можно командой:

Для ручного указания кодировке в Linux Mint, Debian или ubuntu нужно отредактировать конфигурационный файл /etc/locale.gen :

Команду sudo не нужна, если Вы зашли как суперпользователь. Это относится к Linux Mint и Ubuntu, так как Debian ничего не знает о команде sudo.

Стоит обратить внимание, что первые 2 символа (в нашем примере это ru) говорят нам о языке локализации (кириллица).

После этого переопределяем настройки locales командой:

Команда locale-gen позволяет запустить скрипт /etc/locale.gen и перечитывает все кодировки для консоли.

Чтобы увидеть кириллицу в консоли Linux, остается только перелогиниться.

Кракозябры в консоли Ubuntu/Debian

Кракозя́бры (крякозя́бры) — жаргонизм, обозначающий бессмысленный с точки зрения читателя набор символов, чаще всего получаемый на компьютере в результате неправильного перекодирования осмысленного текста. В единственном числе — вообще любой компьютерный символ, для которого в русском языке нет общеизвестного названия, например, значок @. Чаще всего кракозябры образуются на выводе программ по причине неправильно настроенной кодировки символов, а также из-за использования неподходящего шрифта.

Пара примеров из того же Wiki:

А теперь перейдём к решению.

Для редактирования отображения симвлов в консоли существует специальный конфигуратор который запускается такой командой:

Далее все действия производятся в консольном графическом конфигураторе простым выбором необходимых пунктов с помощью кнопок вверх, вниз и “Enter”.