Задача: определить ширину текста (в колонках) перед его выводом на линуксовый терминал.

Планирую определить ширину строки как сумму ширин входящих в строку символов.
Каждый символ может занимать 0, 1 или 2 знакоместа:

• 0 - непечатаемые кодепоинты, а также кодепоинты, добавляющие какую-нибудь закорючку к предыдущему символу
• 1 - обычные символы, напр, латинские или русские буквы
• 2 - напр, китайские иероглифы, занимающие два знакоместа

Решение должно быть изолированным (т.е., не должно зависеть от текущих настроек эмулятора терминала, в котором работает скрипт). Если случится такое, что в разных моноширинных шрифтах какой-то символ имеет то обычную, то двойную ширину, то можно выбрать любую ширину для этого символа: и 1, и 2.

Как отличить символы обычной ширины от двойной ширины, я нашёл: нужно посмотреть свойство EastAsianWidth в Unicode Character Database

А как понять, что символ нулевой ширины (т.е., не увеличивает ширину строки)?
Будет ли достаточно смотреть только на название категории символа без учёта доп. свойств символа?

Список всех категорий

C  = "Other",
Cc = "Control",
Cf = "Format",
Cn = "Unassigned",
Co = "Private_Use",
Cs = "Surrogate",
L  = "Letter",
LC = "Cased_Letter",
Ll = "Lowercase_Letter",
Lm = "Modifier_Letter",
Lo = "Other_Letter",
Lt = "Titlecase_Letter",
Lu = "Uppercase_Letter",
M  = "Mark",
Mc = "Spacing_Mark",
Me = "Enclosing_Mark",
Mn = "Nonspacing_Mark",
N  = "Number",
Nd = "Decimal_Number",
Nl = "Letter_Number",
No = "Other_Number",
P  = "Punctuation",
Pc = "Connector_Punctuation",
Pd = "Dash_Punctuation",
Pe = "Close_Punctuation",
Pf = "Final_Punctuation",
Pi = "Initial_Punctuation",
Po = "Other_Punctuation",
Ps = "Open_Punctuation",
S  = "Symbol",
Sc = "Currency_Symbol",
Sk = "Modifier_Symbol",
Sm = "Math_Symbol",
So = "Other_Symbol",
Z  = "Separator",
Zl = "Line_Separator",
Zp = "Paragraph_Separator",
Zs = "Space_Separator",

Состав категорий

Система: Debian MATE
Проблема: нажатие сочетаний клавиш Ctrl-Shift-1..9 не доходит до приложения (текстового редактора SciTE)

Я не могу забиндить доп. функцию редактора на сочетание клавиш Ctrl-Shift-1
При этом с буквенными клавишами, напр, Ctrl-Shift-q, проблем нет
Судя по косвенным признакам, дело не в этом конкретном редакторе, то же самое будет с любым GUI приложением

Я не знаю, что означают эти сочетания клавиш Ctrl-Shift-1..9 (гуглил, ничего не нашёл) и почему они не доходят до приложения.
В настройках «System -> Preferences -> Keyboard shortcuts» эти сочетания клавиш не назначены. В dconf-editor тоже ничего не нашёл.

Буду благодарен за информацию о том, как мне настроить свою систему, чтобы вернуть пользователю контроль над этими сочетаниями клавиш. Или хотя бы с какой стороны копать, чтобы найти причину.
Такой наглости (решить за пользователя, что эти кнопки ему не нужны, и отобрать) даже винда себе не позволяет…

xev при нажатии Ctrl-Shift-1 пишет:

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40744552, (4,688), root:(41,751),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40744760, (4,688), root:(41,751),
    state 0x14, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40745070, (4,688), root:(41,751),
    state 0x15, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes: (21) "!"
    XmbLookupString gives 1 bytes: (21) "!"
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40745194, (4,688), root:(41,751),
    state 0x15, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes: (21) "!"
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40745593, (4,688), root:(41,751),
    state 0x15, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x3200001,
    root 0x365, subw 0x0, time 40745622, (4,688), root:(41,751),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

На одном шаред-хостинге у каждого юзера путь к файлам своего сайтика начинается с /home/www/yourdomain/

readlink говорит, что:
/home - это ссылка на папку /srv/home/home/,
/srv/home/home - это ссылка на домашнюю папку текущего юзера (путь зависит от имени юзера).

Получается, что разные юзеры читают один и тот же линк /srv/home/home, но попадают по этому линку в разные папки.
Я проверил через [-с /srv/home/home] - это обычный линк на папку, а не девайс.
Неужели в линуксе есть стандартный способ нарушить консистентность файловой системы?
Они как-то монтируют в путь /srv/home/ каждому юзеру свою папку, в которой лежит его персональный симлинк?
Как такое можно сделать?

Недавно я обнаружил странность: распаковка огромного (45Гб) многотомного архива завершилась с ошибкой, но последующее тестирование этого же архива показало, что ошибок нет.
Я удивился, ещё несколько раз протестировал этот архив, и холодок ужаса пробежал по моей спине: архив тестировался то как исправный, то как ошибочный, причём ошибки возникали на разных томах архива, случайно.
Это могло означать лишь одно: мой комп (стоимостью больше моей месячной зарплаты) начал глючить. Я никогда в жизни не разгонял никакие частоты и всегда ценил надёжность выше производительности, а тут такое…

(это была драматичная завязка, дальше идёт техническая часть и неожиданный финал)

Я приступил к определению источника неисправности, планируя проводить тестирование после замены каждого компонента системы.
Тестировал я многократным (60 раз) чтением архива с подсчётом MD5 каждого тома.
Замечу, что общий объём архива больше, чем размер моей оперативы, поэтому происходило 60 считываний именно с диска.

for i in {1..60}; do md5sum *.rar > $(date +%s.txt); done; md5sum *.txt

На экране отобразились 60 хэш-сумм, из которых большинство совпадали, но 8 штук отличались. Внутри каждого из этих 8 .txt файлов отличалась хеш-сумма лишь какого-то одного тома архива, каждый раз разного.
Короче говоря, при чтении файлов с диска возникает в среднем одна ошибка на 350Гб.

На компе у меня один HDD, разбитый на два раздела: ntfs и ext4.
Загрузиться можно с линукса или с винды.
Винда видит только ntfs, линукс видит оба раздела.
Файлы с архивом лежат на ntfs разделе, а загружаюсь я в линукс.

Первым делом я скопировал эти файлы с ntfs на ext4 и повторил тестирование. К моему удивлению, получилось 0 ошибок из 60.
Вторым делом я загрузился в винду и повторил тестирование файлов, лежащих на ntfs-разделе (пришлось написать скриптик, который делает то же самое, что и тот однострочник на bash). Я удивился ещё больше, потому что и здесь всё было в порядке: 0 ошибок из 60.
И тут до меня дошло: ошибка - чисто софтовая, а железо у меня исправное!
Выдох облегчения.

Будь проклят тот день, когда я сел за баранку этого дебиана! )))
У меня debian 9, ntfs-драйвера «искаропки».
Прошу вас повторить мой эксперимент и поделиться результатами, если у вас есть ntfs-раздел на винте с полусотней гигабайт хлама на нём.