Проблема с программой expand (в Debian)

[MiK13]

Решил, чтобы файл с полями, разделёнными табуляцией, выглядел "красиво" воспользоваться программой expand.
И увидел, что выравнивания всё равно нет.
Обнаружил, что эта программа неправильно преобразует табуляции в пробелы. То есть вычисляет сколько надо вставить пробелов, считая текущую позицию не в знаках, а в байтах.
Пришлось даже воспользоваться преобразованием через cp1251:
iconv -t cp1251 FILE_WITH_TAB | expand -t 20 | iconv -f cp1251 >FILE_WO_TAB
Но, так как у нас есть ещё и компьютер с RHEL, решил проверить программу оттуда.
И оказалось, что она преобразует правильно. Скопировал её на свой компьютер (у меня Debian 9)

Код: Выделить всё

mik13@mik13:/run/shm$ echo -e "asd\tasdf\nфыв\tasd" | expand
asd     asdf
фыв  asd
mik13@mik13:/run/shm$ echo -e "asd\tasdf\nфыв\tasd" | ./expand
asd     asdf
фыв     asd

Чем это можно объяснить?
Версия в Stretch более новая:

Код: Выделить всё

mik13@mik13:/run/shm$ expand --version
expand (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <http://gnu.org/licenses/gpl.html>
Это свободное ПО: вы можете изменять и распространять его.
Нет НИКАКИХ ГАРАНТИЙ до степени, разрешённой законом.

Автор программы -- David MacKenzie.
mik13@mik13:/run/shm$ ./expand --version
expand (GNU coreutils) 8.22
Copyright (C) 2013 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <http://gnu.org/licenses/gpl.html>
Это свободное ПО: вы можете изменять и распространять его.
Нет НИКАКИХ ГАРАНТИЙ до степени, разрешённой законом.

Автор программы -- David MacKenzie.

Проверил 32-битную версию из Wheezy -- такая же проблема.
Взял программу версии 8.30 -- то же самое.

[/dev/random]

Некоторые дистрибутивы используют неофициальные патчи, добавляющие поддержку utf-8 в expand, fold и некоторые другие утилиты для работы с текстом из состава coreutils. Официально в них многобайтовые кодировки не поддерживаются.

[MiK13]

Некоторые дистрибутивы используют неофициальные патчи, добавляющие поддержку utf-8 в expand, fold и некоторые другие утилиты для работы с текстом из состава coreutils. Официально в них многобайтовые кодировки не поддерживаются.

Жаль. И довольно странно. Потому, что UTF-8 сейчас довольно широко (на мой взгляд) применяется.
Проверил программу fold.
Дебиановская версия разделяет именно по байтам. В результате в конце и в начале может оказаться знак �
И непонятно, что делает опция -b.
А вот в версии из RHEL эта опция работает корректно.
То есть при её указании она строки действительно формирует с учётом заданной длины, но байты не разделяет.
А если -b не указывать, то и в русском тексте формирует строки заданной длины.

Может быть со временем это введут и в официальную версию? Тем более, что, как я понимаю, просто надо вместо char использовать wchar_t и соответствующие функции ввода/вывода. (выводить по %lc и %ls вместо %c и %s).

[s.xbatob]

Тем более, что, как я понимаю, просто надо вместо char использовать wchar_t и соответствующие функции ввода/вывода. (выводить по %lc и %ls вместо %c и %s).

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

[MiK13]

там всё не так просто. Сначала надо текст декодировать из внешней кодировки во внутреннюю, потом обработать и кодировать обратно.

Но и особо сложного я не вижу.
Использовать для чтения функции типа fgetwc и fgetws вместо fgetc и fgets. Соответственно и для вывода.
Или формат %lc и %ls вместо %c и %s. На знак табуляции это никак не повлияет.
Кроме того, непонятен смысл опции -b в программе fold.

А утилита эта, мягко говоря, не слишком востребованная, так что перемен ждать не стоит.

Что касается fold, действительно пока не могу представить, для чего она может понадобиться.
А вот нормально работающий expand мне очень хотелось бы иметь. Тем более, что авторы RHEL и CentOS (Fedora не смотрел) это сделали.

Ещё хотелось бы иметь программу sort аналогичную программе sort из DOS. В ней можно было задать начальную позицию строки, начиная с которой производится сравнение строк. В UNIX версии задаётся поле. Это удобно, но не всегда.

[olecya]

пока не могу представить, для чего она может понадобиться.

Оч удобно разбить строку

Код: Выделить всё

fold -w1 <<<моя' 'строка
fold -c1 <<<1234567890

Добавлено (18:15):

Код: Выделить всё

fold -c1 <<<моя' 'строка | sort
comm --nocheck-order -3 <(fold -c1 <<<1234567890) <(seq 12)

[MiK13]

Оч удобно разбить строку

Код: Выделить всё

fold -w1 <<<моя' 'строка
fold -c1 <<<1234567890

Код: Выделить всё

$ fold -c1 <<<1234567890
fold: неверный ключ — «c»
По команде «fold --help» можно получить дополнительную информацию.

[olecya]

fedora 30
man fold

-c, --characters count characters rather than columns

Специально заглянула в мануал дебиана bullseye и не нашла этой опции

[MiK13]

fedora 30
man fold

-c, --characters count characters rather than columns

У меня сейчас нет "под рукой" линукса на основе Red Hat, но что-то помнится, в RHEL была опциф -b, а не -c.

Специально заглянула в мануал дебиана bullseye и не нашла этой опции

Видимо разработчики дебиана не очень серьёзно отнеслись к этой программе
Думал даже самому написать подобную программу (работающую через wchar_t), но потом решил, что раз есть версия из RHEL/CentOS, этого делать не нужно.

P.S. Что-то я в конце дня стал путаться с программами :-)
Писал, в принципе, про fold, а думал про expand.
В man fold эта опция -b.
Причём, она в качестве параметра принимает длину. Которая указывается через -w

[MiK13]

Ещё хотелось бы иметь программу sort аналогичную программе sort из DOS. В ней можно было задать начальную позицию строки, начиная с которой производится сравнение строк. В UNIX версии задаётся поле. Это удобно, но не всегда.

Оказалось, что линуксовый sort тоже позволяет этот делать. Надо только после -k указать 1.n, где n -- номер позиции, с которой нужно сортировать текст.
Но и здесь оказалась та же проблема. Номер позиции -- это не номер знака, а номер байта в строке.
А вот для sort из CentOS это именно номер знака.

[MiK13]

Специально заглянула в мануал дебиана bullseye и не нашла этой опции

А где взяли мануал bullseye? Он же ещё не вышел официально. Последняя версия -- Buster (10).

[Aliech]

Специально заглянула в мануал дебиана bullseye и не нашла этой опции

А где взяли мануал bullseye? Он же ещё не вышел официально. Последняя версия -- Buster (10).

А он разве недоступен? Вот я сейчас пишу сообщение, а у меня:

Код: Выделить всё

aliech@arcturus:~$ cat /etc/debian_version 
bullseye/sid

[MiK13]

А где взяли мануал bullseye? Он же ещё не вышел официально. Последняя версия -- Buster (10).

А он разве недоступен? Вот я сейчас пишу сообщение, а у меня:

Код: Выделить всё

aliech@arcturus:~$ cat /etc/debian_version 
bullseye/sid

В принципе, наверно, доступен. Только я пока не знаю как его установить.
И в обычной системе Debian в файла /etc/debian_version находится не название версии, а её номер. На работе у меня просто 9.11, а дома 10.3.
А вот когда я поставил Mint, то в нём в этом файле было buster/sid.
Когда-то я на нетбук попробовал поставить какую-то testing версию, но она работала плохо. В отличие от стабильной, которую поставил при её выходе.

[Aliech]

MiK13, попробуйте testing как основную рабочую версию для десктопа*. Да, там бывают внезапные проблемы при массовом завозе пакетов (такое бывает через некоторое время после выхода следующего стабильного дистрибутива, так как внезапно начинается массовый завоз версий из usntable), но это происходит редко. Раньше самыми проблемными были драйвера на видюхи, которые всегда отставали от свежих версий ядра и xorg'а, но сейчас и с этим особых проблем нет. Если у вас не Невидия.

В чём профит от всего этого? Будете знать, как выглядит ожидаемый выпуск ОС до релиза. Ну и да, свежие версии ПО иногда очень удивляют своей эволюцией. У меня даже на работе testing на рабочей станции. И да, у соседей по кабинету stable (да, я внедрил Debian на рабочие машины, он у нас даже в формуляры рабочих мест вписан). Часто бывает так, что у меня уже что-то удобней происходит, чем у них.

* Для личного десктопа, конечно же. Своего. Другим людям testing ставить не надо. Совсем.

// пропаганду testing'а проводить прекратил

[MiK13]

MiK13, попробуйте testing как основную рабочую версию для десктопа*. Да, там бывают внезапные проблемы при массовом завозе пакетов (такое бывает через некоторое время после выхода следующего стабильного дистрибутива, так как внезапно начинается массовый завоз версий из usntable), но это происходит редко.

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

Раньше самыми проблемными были драйвера на видюхи, которые всегда отставали от свежих версий ядра и xorg'а, но сейчас и с этим особых проблем нет. Если у вас не Невидия.

Так в том-то и дело, что у меня на последнем собранном компьютере ASUS Phoenix GeForce GTX 1650, а она NVIDIA.
Дома у меня два монитора. Но один из них имеет только RGB VGA интерфейс. Попробовал его подключить через старую карту 210, но она не запустилась. И в Debian Buster вообще не запустились иксы. В Linux Mint запустились, но только на основной монитор (подключенный через Display Port). Хотя на этапе загрузки эмблема выскакивала на втором.
Была проблема с ноутбуком. В Buster не запустились иксы. Правда, они запустили после установки ядра 5.4 Но Wi-Fi запустить пока не удаётся. Хотя в Linux Mint 19 он работает. Но хочу Debian

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

Когда-то мне понравился GNOME. Но после перехода но новую версию оказалось, что в нём GNOME3. И у меня многое перестало работать. Восстановить в основном удалось. Но GNOME перестал нравится. Скорее всего буду использовать XFCE.
И несколько раз было, что после перехода на новую версию терялись некоторые вещи, к которым я привык. Но плюсы всё-таки заметно перевешивали
И больше всего мне не нравится то, ради чего я создал эту тему. А именно некорректная работа некоторых программ по обработке текста:
expand, fold и частично sort. Они работают не со знаками (которые в UTF-8 могут быть двухьбайтовыми, а с байтами. Это в Debian и, похоже, в Arch. А вот d RHEL и CentOS они работают корректно.

// пропаганду testing'а проводить прекратил

Для меня главное чтобы программы хорошо работали. А какая версия системы меня не очень волнует. На "Сервере" на работе у нас до сих пор стоит Lenny и я не собираюсь его менять. Так как у него всего две функции: хранение файлов с проектами и доступ в интернет.
P.S. Одно время пытался использовать последнюю версию LibreOffice, но после того, как столкнулся с тем, что он стал при запуске вместо образцов первых страниц показывать чёрные прямоугольники, решил работать с той версией, которая поставляется с Buster.
Правда, причина в этом не самом офисе, а в каких-то настройках. Тот же офис под в другом домашнем каталоге работает нормально.

[MiK13]

Сейчас обнаружил аналогичную проблему и с программой uniq. В Debian 9
Есть файл russian.dic. В нём 2376434 русских слов (в разных формах). В алфавитном порядке. Но сначала слова с заглавных букв, а затем -- со строчных. Причём, в UTF-8.
Но команда /usr/bin/uniq -w1 russian.dic выдаёт только первую строчку.
А вот uniq из CentOS выдаёт по первой строчки из каждой группы слов, начинающихся с одинаковой буквы.
Почему у Debian это не так?