LINUX.ORG.RU

Буква Л=?

 , ,


1

1

Объясните новичку, что с буквой Л-большое:

$ nano -w Лето &
[3] 3299

$ ps axww | grep 3299
 3299 pts/0    T      0:00 nano -w ?ето

Проверялось на gentoo, Ubuntu 18.04.4 LTS bionic
Для ubuntu:

$ locale 
LANG=ru_RU.UTF-8
LANGUAGE=ru
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=


Это реакция не на «Л», а на заглавную в принципе. Попробуй ENG получишь то же. Почему – я не в курсе. Кто-то видимо или говна пожрал или IBM-вирус какой цепанул…

P.S.: хотя нет. Но вообще такое уже видел и не только для «Л». Но сейчас могу только для заглавной «Л» найти пример. Странно это всё.

P.P.S.:

   8542 pts/0    T      0:00 nano -w АБВГДЕЁЖЗИЙК?МНОПРСТУФХЦЧШЩЪЫЬЭЮЯфбвгдеёжзийклмнопрстуфхцчшщъыьэюя

и

8567 pts/0    T      0:00 nano -w ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

и, на последок, с ударением

nano -w LÓR &
# 8622 pts/0    T      0:00 nano -w LO?R

kostyarin_ ★★ ()
Последнее исправление: kostyarin_ (всего исправлений: 2)
Ответ на: комментарий от torvn77

Тогда уж лучше только цифрами пользоваться. Имена файлов, увы, /home/user/pix/Лютик.jpg, /home/user/pix/Лилия.jpg и т.д. Требуется найти открытые файлы с этими именами и закрыть их. Не нашел ничего лучше как ps axww | grep «$filename», а потом kill их.

novus ()

«Л» в UTF-8 кодируется байтами 0xd0 0x9b. ps из procps «на всякий случай» защищается от 0x9b, потому что боится, что терминал может воспринять 0x9b как однобайтный CSI, и поэтому заменяет любую кодовую последовательность с 0x9b на ‘?’.

i-rinat ★★★★★ ()
Ответ на: комментарий от kostyarin_

LÓR

0x4c 0x4f 0xcc 0x81 0x52

COMBINING ACUTE ACCENT, то есть U+0301, не является печатным символом, и ps заменяет его на ?. Вот так вот он (не) поддерживает юникод: обрабатывает кодовые позиции по одной за раз.

i-rinat ★★★★★ ()
Ответ на: комментарий от gedisdone

Видит. Более того, вся эта замена делается только для локалей с UTF-8. Забавно, да?

Как я уже сказал, это какая-то защита от терминалов, которые ломаются от 0x9b. Бредовенько, да.

А, да. Ему не надо, чтобы последовательность начиналась на 0x9b. Он смотрит во все байты.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от novus

Имена файлов, увы, /home/user/pix/Лютик.jpg,

Такого рода файлы обычно через консоль не перерабытываются.

Хотя да, помимо изображений есть ещё и произведения литературы, но их может правильнее хранить в специальной индексированной БД?

torvn77 ★★★★★ ()
Ответ на: комментарий от i-rinat

Спасибо за разъяснение, мастерски.

Наверное, нужно все (вывод ps и имена фалов) перекодировать в не UTF-8, но что-то мне подсказывает, что будут проблемы. Или, проще, реализовать кастомное сравнение строк, учитывая 'Л' - это '?'.

novus ()
Ответ на: комментарий от novus

Лучшим решением тут будет запатчить ps, чтобы он такого экранирования больше не делал. В нём нет смысла, потому что если терминал ломается от «Л», проблемы с ps будут не самой главной заботой пользователя. Этому коду пятнадцать лет. Его как добавили, так больше и не трогали. Видимо, пришло время.

i-rinat ★★★★★ ()

Arch Linux

$ nano -w лето &

[1] 410029[br]

[2] 410030[br]

$ ps axww | grep 410029

user 410029 0.0 0.0 9932 3488 pts/1 T 16:36 0:00 _ nano -w лето

user 410119 0.0 0.0 9148 2296 pts/1 S+ 16:37 0:00 _ grep 410029

$ locale

LANG=pl_PL.UTF-8

LC_CTYPE=«pl_PL.UTF-8»

LC_NUMERIC=pl_PL.UTF-8

LC_TIME=pl_PL.UTF-8

LC_COLLATE=«pl_PL.UTF-8»

LC_MONETARY=pl_PL.UTF-8

LC_MESSAGES=«pl_PL.UTF-8»

LC_PAPER=pl_PL.UTF-8

LC_NAME=pl_PL.UTF-8

LC_ADDRESS=pl_PL.UTF-8

LC_TELEPHONE=pl_PL.UTF-8

LC_MEASUREMENT=pl_PL.UTF-8

LC_IDENTIFICATION=pl_PL.UTF-8

LC_ALL=

diatryba ()
Ответ на: комментарий от novus

Мысль дельная, спасибо.

Файловая система и есть БД. Так что мысль так себе. Если есть проблема использования отличного от английского строчного беспробельного бесдефисного бездиакритического (и т.д. и т.д.п.), то решать нужно её, а не придумывать какую-то херню.

kostyarin_ ★★ ()
Ответ на: комментарий от torvn77

А может лучше сразу и английский не использовать - тупо пойти смотреть мемасы и лайки в инсте ставить ? Хотя действительно кому вообще сдался этот родной язык, может ещё и маму с папой людить и уважать прикажете….

AKonia ★★ ()
Ответ на: комментарий от torvn77

Такого рода файлы обычно через консоль не перерабытываются.

только на щвятом жападе умеют не мышевозить?

хранить в специальной индексированной БД?

линупсовые фс настолько не годны для хранения файлов?

anonymous ()
Ответ на: комментарий от AKonia

Хотя действительно кому вообще сдался этот родной язык

Всё проще: национальный язык это практическая эксплуатация ОС пользователем под гуем и там национальный язык дейсьвительно нужен, а консоль она не для повседневной жизни, она для администрирования, конфигурирования и отладки приложений и это лучше делать на едином для всего мира языке, другие языки приведут только к усложнению кода, распылению усилий и путанице.

П.С. Но конечно баг с заглавными буквами следует исправить.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от i-rinat

мак

С важностью и чувством презрения к простым смертным.

Система, кстати, довольно тупая. Особенно терминал после Linux-а. Home/End по строке не работают. Что там у них за сочетания вместо этого (а главное зачем) не понятно. Ну и так далее.

kostyarin_ ★★ ()
Последнее исправление: kostyarin_ (всего исправлений: 1)
Ответ на: комментарий от torvn77

другие языки приведут только к усложнению кода

Для C/C++ говна да. А вообще, сейчас уже поддержка UTF-8/16/32 в языке считается нормой. Иными словами, старый хлам поддерживать хлопотней. Это да.

Только проблема не в хламе, а в ЯП, на котором они написаны. Удивительный кульбит Уробороса (с целью укусить себя за жопу) – эта поддержка старого хлама. В С/C++ ничего не меняют (backward compatibility), чтобы поддержка старого говна оставалась веками. В старом говне ничего не меняют, потому что придётся много переделывать на новый лад. Новшества для сохранения старого дерьма в неизменном, статическом, состоянии. Как и Ваша мантра – «делать всё как встарь на века» – не более чем Плюшкинство.

kostyarin_ ★★ ()
Ответ на: комментарий от kostyarin_

сейчас уже поддержка UTF-8/16/32

Дело не только вкодировке, но и в необходимости поддерживать переводы сообщений и манов на разные языки и связанное с этим разрушение единства терминологии.

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

В то же время если мы говорим в образах, то использование английского языка носителем русского сродни интерпретации байткода вместо прямого двоичного исполнения, со всеми вытекающими, будь то уменьшенная скорость усвоения новой информации, в коде же это порождает порог недопонимания, в виду которого разработчику придётся тратить время чтобы выучить очередное неочевидное сокращение или постоянно перестраиваться с родного языка образов в заморский назывательный

AKonia ★★ ()
Ответ на: комментарий от kostyarin_

Сравнение pid'ов быстрее. Это даже лучше, но решение не универсальное (pid может быть неизвестен).

Закомментировал ветку if (memchr(src, 0x9B, len)) в escape.c, перекомпилировал procps-ng:

$ ./configure --prefix=/home/user/temp/procps-ng; make; make install
И всё получилось:
$ ps axww | grep nano
 5980 pts/6    T      0:00 nano -w ?ето
 6105 pts/6    S+     0:00 grep --colour=auto nano
cd /home/user/temp/procps-ng/bin
$ ./ps axww | grep nano
 5980 pts/6    T      0:00 nano -w Лето
 6116 pts/6    S+     0:00 grep --colour=auto nano

Спасибо!

novus ()
Ответ на: комментарий от torvn77

Дело не только вкодировке, но и в необходимости поддерживать переводы сообщений и манов на разные языки и связанное с этим разрушение единства терминологии.

  1. Ага, русские имена файлов разрушают терминологию. Поверил.
  2. Маны никто не читает. Они составлены бездарно в большинстве случаев. Ими пользуются только по тому, что читать больше нечего в принципе.
  3. Как образуются термины и как они используются? Давайте лоропеду доверим решать.
  4. «Когда разделителем дробной части выступает запятая у меня замыкает мозг» – из той же оперы.
  5. И т.д. и т.п.
kostyarin_ ★★ ()
Ответ на: комментарий от anonymous

Сам не могёшь, чтоле? %/

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

anonymous ()
Ответ на: комментарий от i-rinat

Этому коду пятнадцать лет. Его как добавили, так больше и не трогали. Видимо, пришло время.

Некто Jim Warner запатчил ps и теперь это просто история. Отчасти и благодаря тебе.

https://gitlab.com/procps-ng/procps/-/issues/176 [closed]

kostyarin_ ★★ ()