Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Решал обычно как-то так:
sudo apt-get install console-cyrillic
echo cyr >> ~/.bashrc
Если склероз подводит, это пакет не рекомендовался к использованию где-то с 11.хх. Причин, за давностью лет, не упомню — что-то он там то ли ломал, то ли не срабатывал.
Потому, в своё время, прикрутил для той же цени setupcon и успокоился
Потому, в своё время, прикрутил для той же цени setupcon и успокоился
Всегда делал так: http://help.ubuntu.ru/wiki/russian_font_in_console
На 16.04 тоже сработало.
На той же странице Ваш «костыль» во вредных советах. И я с ними согласен.
На 16.04 тоже сработало.
На той же странице Ваш «костыль» во вредных советах. И я с ними согласен.
Вот жеж! И не лень было докопаться до истоков! Решительно плюсую.
Меня хватает только на `dpkg-reconfigure console-setup` и вызов `setupcon` где-то в /etc/rc.local или даже в ~/.bashrc.
Кстати, убунта этим страдает как минимум с 10.04 — ещё жив под рукой сервер, на котором проводились подобные «пляски с бубном»
Меня хватает только на `dpkg-reconfigure console-setup` и вызов `setupcon` где-то в /etc/rc.local или даже в ~/.bashrc.
Кстати, убунта этим страдает как минимум с 10.04 — ещё жив под рукой сервер, на котором проводились подобные «пляски с бубном»
Просто ад какой-то. В слаке всё гораздо проще. Дайте неграм Linux и они его извратят и усложнят до невозможности. Убунту второй виндовс и не нужен ни под каким соусом. Даже мята не спасает, один хрен дерьмом тянет.
Я очень люблю Linux, но к сожалению, в актуальных версиях Windows нет таких проблем. Так что это даже не второй Windows. Это просто Ubuntu.
В актуальных версиях Windows не просто дофига таких проблем, там их ещё больше, чем было в неактуальных. Ибо если во времена 9x было ansi и oem, читай windows-1251 и ibm866, то теперь ещё появились разные вариации юникода, в том числе utf-8 с bom (некорректный — в utf-8 не должно быть bom).
Регулярно приходится отлавливать хрень в сообщении об ошибке в непонятно какой кодировке. Бывает, что в соседних строках, из которых составляется одна общая — разные кодировки. А ошибки эти надо решать.
А апофеозом ситуации является IBM Lotus Domino, который мало того, что сам выдаёт сообщения в SMTP-сессию не в латинице (чего нельзя делать по стандарту — кодировка и язык на этом этапе не согласовываются), так ещё и некоторые системные сообщения выдаёт прям в SMTP-сессию в той кодировке, в которой ему отдала винда, то есть, не в той, в которой говорил сам. Когда его ставишь в линуксе, такой порнографии не видно.
Регулярно приходится отлавливать хрень в сообщении об ошибке в непонятно какой кодировке. Бывает, что в соседних строках, из которых составляется одна общая — разные кодировки. А ошибки эти надо решать.
А апофеозом ситуации является IBM Lotus Domino, который мало того, что сам выдаёт сообщения в SMTP-сессию не в латинице (чего нельзя делать по стандарту — кодировка и язык на этом этапе не согласовываются), так ещё и некоторые системные сообщения выдаёт прям в SMTP-сессию в той кодировке, в которой ему отдала винда, то есть, не в той, в которой говорил сам. Когда его ставишь в линуксе, такой порнографии не видно.
Кто выдает эти сообщения об ошибках? Приложения, идущие в составе дистрибутива Windows или приложения сторонних разработчиков, как Lotus Domino?
Сообщения системные, типа «файл не найден». В Bacula, например, нет таких сообщений вообще.
То есть, возвращает ИМЕННО система.
Вообще, я вас обязан расстроить: чтобы это исправить, придётся отказаться от обратной совместимости и перевести всё — cmd тоже — на рельсы utf-8. И тогда куча уже имеющихся бинарников будет отображать кракозябры, но зато проблем типа «запустил dir > file.txt, открыл блокнотом — вижу кракозябры» не будет.
То есть, возвращает ИМЕННО система.
Вообще, я вас обязан расстроить: чтобы это исправить, придётся отказаться от обратной совместимости и перевести всё — cmd тоже — на рельсы utf-8. И тогда куча уже имеющихся бинарников будет отображать кракозябры, но зато проблем типа «запустил dir > file.txt, открыл блокнотом — вижу кракозябры» не будет.
> в utf-8 не должно быть bom
Почему? А как его отличить от различных вариантов UTF-16?
Почему? А как его отличить от различных вариантов UTF-16?
У UTF-16 всегда есть сигнатура. Тем не менее для UTF-8 иногда полезно иметь BOM, ибо для обнаружения что перед нами документ в UTF-8 те ещё костыли в редакторах используют, которые не всегда срабатывают (если например в поток вкрались вдруг местами одиночные байты типа \x00 и прочий мусор).
Пользователь должен явно сообщать приложению, читающему поток символов, какую кодировку использовать.
Как пользователь эту кодировку узнает — его проблемы, но класть подсказки внутрь самого текста (BOM) — одна из худших идей ever.
Как пользователь эту кодировку узнает — его проблемы, но класть подсказки внутрь самого текста (BOM) — одна из худших идей ever.
Никак. Её просто не должно быть в интерфейсах. Просто, все интерфейсы, абсолютно все, должны быть в одной кодировке.
И UTF-16 не подходит уже потому, что она не имеет определённого порядка байтов. UTF-8 же его имеет (всегда «сетевой порядок»), поэтому BOM в ней быть не может. Какой может быть byte order mark в кодировке, в которой byte order однозначно зафиксирован?
И UTF-16 не подходит уже потому, что она не имеет определённого порядка байтов. UTF-8 же его имеет (всегда «сетевой порядок»), поэтому BOM в ней быть не может. Какой может быть byte order mark в кодировке, в которой byte order однозначно зафиксирован?
некорректный — в utf-8 не должно быть bomПравильно будет: «в utf-8 может не быть bom». utf-8 с BOM — не является некорректным. BOM — это просто конкретный юникодный символ 0xFEFF, стандарт не мешает его использовать в utf-8 (хотя не рекомендуется), так же как не заставляет использовать в других кодировках юникода.
Хм, очень любопытно, всегда считал, что BOM это обязательный элемент UTF8, который нам позволяет понять собственно что за кодировка перед нами. Правда, ловил я много приколов с ним, например при (де)сериализации XML, небезызвестная ошибка Data at the root level is invalid. Line 1, position 1. заставляла использовать new UTF8Encoding(false), но в остальных случаях я все равно её использовал… Спасибо за информацию, буду теперь избегать бома.
Вас не затруднит объяснить, причем тут негры?
Может вопрос не совсем в тему, но тем не менее. Я когда последний раз на убунту смотрел, там переключение раскладки по Alt+Shift настроить нельзя было. И пару релизов ещё не работало оно. Что там сейчас? Починили?
Да, починили.
А проблема с гаснущим NumLock при смене раскладки еще наблюдается, не знаете?
Судя по launchpad задача открыта…
Судя по launchpad задача открыта…
Тут так уверенно ответить не смогу. Если на раскладку я обращал внимание, и знаю про что спрашивал poxu (сам страдал от этого) — то с NumLock никогда не воевал. Сижу на 14.04, проверил — всё ок, состояние сохраняется при смене раскладки.
К сожалению, проблема не в том, что гаснет, а в том, что потом цифровой блок ведет себя рандомно в разных приложениях.
Где-то включен, где-то выключен, а где-то нечто среднее. Например, 2/4/6/8 работают как стрелки, а остальные — как цифры.
Где-то включен, где-то выключен, а где-то нечто среднее. Например, 2/4/6/8 работают как стрелки, а остальные — как цифры.
А еще вопрос аналогичный, можно ли сейчас в убунте назначить переключения отдельных раскладок на отдельные комбинации клавиш? Например для трех разных языков назначить Ctrl+1, Ctrl+2 и т.д.
Вы можете настроить произвольную фигню через custom shortcut, назначив комбинацию клавиш на самописную баш-команду.
System Settings — > Keyboard -> Shortcuts -> Custom Shortcuts
создаем новый «Custom Shortcut», даем какое-то ему имя в поле «Name» (например,
EN или RU), в поле «Command» прописываем:
— эта команда будет переключать клавиатуру на раскладку которая идет первой (ну вернее нулевой), в списке All Settings -> Text Entry
и назначаем ему сочетание клавиш, например Ctrl+1
соотвественно следующие раскладки будут влючаться командами:
создаем новый «Custom Shortcut», даем какое-то ему имя в поле «Name» (например,
EN или RU), в поле «Command» прописываем:
gsettings set org.gnome.desktop.input-sources current 0
— эта команда будет переключать клавиатуру на раскладку которая идет первой (ну вернее нулевой), в списке All Settings -> Text Entry
и назначаем ему сочетание клавиш, например Ctrl+1
соотвественно следующие раскладки будут влючаться командами:
gsettings set org.gnome.desktop.input-sources current 1
gsettings set org.gnome.desktop.input-sources current 2
gsettings set org.gnome.desktop.input-sources current 3
Раз тут такие крутые линуксоиды собрались, может мне кто-нибудь поможет?
Спасибо, попробовал в вируалке, отлично работает!
ЗЫ Сорри, стрелкой вверх, увы не могу отметить такой подробный и качественный совет (
ЗЫ Сорри, стрелкой вверх, увы не могу отметить такой подробный и качественный совет (
К слову, это всегда можно было прикрутить окольными путями:
setxkbmap «us,ru» ",winkeys" «grp:alt_shift_toggle»
setxkbmap «us,ru» ",winkeys" «grp:alt_shift_toggle»
Сейчас это принято делать так:
«здраствуй» gdm3
gsettings set org.gnome.desktop.wm.keybgdm3indings switch-input-source "['<Alt>Shift_L', '<Alt>Shift_R']"
gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us'), ('xkb', 'ru')]"
«здраствуй» gdm3
Ну незнаааааю, нормальный gdm 3 как по мне :)
А оно научилось переключаться по клавишам-модификаторам?
У меня когда-то был любимым левый Ctrl (да, наследие самописных драйверов клавиатуры под DOS). Сейчас на LXDE/Cinnamon прикручен Caps/Shift-Caps. В своё время отказался от Гнома и «родной» Убунты в частности и из-за этого…
У меня когда-то был любимым левый Ctrl (да, наследие самописных драйверов клавиатуры под DOS). Сейчас на LXDE/Cinnamon прикручен Caps/Shift-Caps. В своё время отказался от Гнома и «родной» Убунты в частности и из-за этого…
«Modifiers-only switch to next source», не?
Возможно.
Года три уже нигде нет «честного» гнома, чтобы попробовать — или cinnamon, или mate вместо него. В Mint/Cinnamon сейчас конфигуратор раскладок как из старого второго гнома, а у остальных, кажется, из гуя не было возможности нсатроить.
Надо, чтобы по Caps был английский, а по Shift-Caps — русский.
Года три уже нигде нет «честного» гнома, чтобы попробовать — или cinnamon, или mate вместо него. В Mint/Cinnamon сейчас конфигуратор раскладок как из старого второго гнома, а у остальных, кажется, из гуя не было возможности нсатроить.
Надо, чтобы по Caps был английский, а по Shift-Caps — русский.
ИМХО не самый правильный способ — привязан к конкретной граф. среде (gdm), а если гном не единственный в системе или его нет вообще?
Правильнее класть это в конфигурацию иксов (к примеру /usr/share/X11/xorg.conf.d в моем дистрибутиве).
Правильнее класть это в конфигурацию иксов (к примеру /usr/share/X11/xorg.conf.d в моем дистрибутиве).
Пропиарил баг. Спасибо за работу!
О, блин… Они это что ли до сих пор не пофиксили? В 8.04 было еще...8 лет прошло.
На вики даже 2 темы было.
http://help.ubuntu.ru/wiki/Русификация_консоли и http://help.ubuntu.ru/wiki/russian_font_in_console
Похоже нужно третью делать.
На вики даже 2 темы было.
http://help.ubuntu.ru/wiki/Русификация_консоли и http://help.ubuntu.ru/wiki/russian_font_in_console
Похоже нужно третью делать.
Ох, Вы зря потратили кучу времени. Проблема решается просто: sudo dpkg-reconfigure locales.
Он сам предложит выбрать кодировки, шрифт, как переключать и запустит locale-gen по завершении…
Он сам предложит выбрать кодировки, шрифт, как переключать и запустит locale-gen по завершении…
Вот только упомянутую в статье проблему это не решает
Ок. Я нашел время на потестить. Тестировал на ubuntu версий 14.04, 15.10, 16.04 beta — нигде проблему не подтвердил. Вы уверены. что все делаете правильно? Я просто все три дистрибутива поставил в VirtualBox, и во время установки указал правильную локаль. После загрузки все было в порядке. Никаких дополнительных манипуляций производить не пришлось.
Рабочая система, Ubuntu 16.04 x64 с обновлениями по состоянию на прямо сейчас. Упомянутую вами команду применял как много раз в прошлом, так и только что специально чтобы перепроверить. В консоли квадратики. У меня и у многих других. У меня не VirtualBox, а на железе система, может, с этим что-то связано, не знаю.
Как минимум одну причину я знаю такой проблемы: drm-модуль видеокарты. Который грузится после настройки vconsole и создаёт новый фреймбуфер, который все настройки соответственно игнорирует. Это не все модули так получаются, потому не у всех проявляются, если хотите сравните с bosha какие модули грузятся. Но вообще не знаю та ли это проблема, и так же ли зловеще она решалась бы в дружественной убунте, как описано в статье, но в недружественном арче я в итоге решил двумя действиями — указанием модуля в прегрзку /etc/mkinitcpio.conf и регенерацией initramfs («mkinitcpio linux» итд).
здесь идет речь о убунту сервере, а вы об убунте наверняка о десктоп (рабочая система)… там действительно нет этой проблемы.
Вот интересно, есть волшебный файл /etc/vconsole.conf, который используется systemd для настройки шрифтов, почему просто им не воспользоваться?
Например, чтобы видеть нормально в консоли названия файлов на русском, чтобы бывает просто необходимо.
Ну суть-то описанной проблемы в том, что шрифт с юникодом не подцепляется. А без него, не только локализованные сообщения не будут работать(которые действительно не сильно-то кому нужны), но и все имена файлов содержащие символы, которых нет в стандартном шрифте, будут поломаны, что уже весьма неприятно. И кодировки тут не при чём в общем-то, как и то, что вы передаёте в LANG.
Сегодня пишем на русском Хабре коммент по русски, завтра будем делать то же самое.
Зачем?
Зачем?
Хороший труд! Спасибо.
Использование только английского интерфейса решает многие проблемы… ;)
Ага, и файлы с русскими именами не имеют прав на существование. А ведь русский — один из официальных языков ООН…
Обхожусь без таких файлов лет 20, до сих пор жив… И да, названия файлов не на английском языке, на мой взгляд, плохая привычка. Нет русского или другого языка (я как подумаю про имя файла на иврите...) в названии файла — меньше проблем.
Konsole на Ubuntu 14.04:
Русский и иврит в консоли, в т.ч. имя файла в котором используются одновременно три языка и с написанием слева направо (англйский и русский) и справа налево (иврит)
Без «ручных» настроек. Языки указанны в наборе клавиатур (Input soursed to use) и в Language Support, в настройках Konsole отмечено «Enable Bi-directional text rendering»
Русский и иврит в консоли, в т.ч. имя файла в котором используются одновременно три языка и с написанием слева направо (англйский и русский) и справа налево (иврит)
Без «ручных» настроек. Языки указанны в наборе клавиатур (Input soursed to use) и в Language Support, в настройках Konsole отмечено «Enable Bi-directional text rendering»
Получается, что в названии файла на иврите расширение идет в начале, а не в конце названия?
В Linux, строго говоря, нет расширений.
В строке содержащей только буквы иврита вся строка будет ориентированна справа налево. Если мы напишем «расширение» на иврите, оно будет слева.
Но, если в строке будут части которые представляют собой текст на языке в котором текст пишется слева направо (английский, русский), то вся строка будет располагаться слева направо, и вставки на иврите будут располагаться в этом же порядке, хотя внутри вставок порядок расположения букв будет обратным — справа налево. Т.е. пока мы пишем на английском буквы добавляются справа, переключились на иврит, они от первой ивритской буквы добавляются слева между первой ивритской буквой и английским текстом, переключились на английский — буквы будут добавляться опять справа.
Что, имхо, логично
И так не только в именах файлов, но и вообще в тексте:
В строке содержащей только буквы иврита вся строка будет ориентированна справа налево. Если мы напишем «расширение» на иврите, оно будет слева.
Но, если в строке будут части которые представляют собой текст на языке в котором текст пишется слева направо (английский, русский), то вся строка будет располагаться слева направо, и вставки на иврите будут располагаться в этом же порядке, хотя внутри вставок порядок расположения букв будет обратным — справа налево. Т.е. пока мы пишем на английском буквы добавляются справа, переключились на иврит, они от первой ивритской буквы добавляются слева между первой ивритской буквой и английским текстом, переключились на английский — буквы будут добавляться опять справа.
Что, имхо, логично
И так не только в именах файлов, но и вообще в тексте:
Это прекрасно, но при работе в консоли жутко неудобно.
Каждый раз переключать раскладку, как только нужно прочитать עִבְרִית.txt, очень быстро надоедает.
А если его ещё и сравнивать придется, скажем, с العربية.txt, то там и вовсе запутаться недолго.
Каждый раз переключать раскладку, как только нужно прочитать עִבְרִית.txt, очень быстро надоедает.
А если его ещё и сравнивать придется, скажем, с العربية.txt, то там и вовсе запутаться недолго.
В Debian testing на первой консоли тоже нету кириллицы. А вот на второй и дальше — есть.
Это если с Plymouth, без него, по крайней мере в Jessie, было все ок, ЕМНИП.
Это если с Plymouth, без него, по крайней мере в Jessie, было все ок, ЕМНИП.
Спасибо за статью, передумал переходить с 14.04 :)
Ubuntu. Русификация консоли в 2016 году
Всегда исправлял простым выставлением CODESET=«CyrKoi», про guess не знал.
Там же можно увеличить приоритет ошибки
Даёшь хабраэффект!
Ставил Ubuntu Server 16.04 Beta 2. После первой загрузки была такая же проблема. Но после apt-get update && apt-get upgrade и ребута — консоль сама поправилась.
Устал читать. Грустно становится за опенсорч, в котором баги не исправляются по пять лет, а регрессии вносятся каждые полгода пачками. В таком положении развитиею опенсорча грозит захлебнуться в собственных проблемах.
Всегда решал «проблему» одной командой cyr в консоли, ещё с бородатых времён дебиана 5.
установил пакет по ссылке https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1565542/+attachment/4625851/+files/keyboard-configuration_1.108ubuntu9_all-fixed.deb
подтверждаю, работает на ubuntu server 16.04 LTS (beta).
напоминаю, устанавливается так:
sudo dpkg -i keyboard-configuration_*.deb
sudo apt-mark hold keyboard-configuration
подтверждаю, работает на ubuntu server 16.04 LTS (beta).
напоминаю, устанавливается так:
sudo dpkg -i keyboard-configuration_*.deb
sudo apt-mark hold keyboard-configuration
Т.к. текстовой консолью пользуюсь очень редко и пользователь один, просто добавил в ~/.bashrc
Спасибо за статью и багрепорт!
setupcon
Спасибо за статью и багрепорт!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ubuntu. Русификация консоли в 2016 году