Серия полезных советов. Текстовые утилиты (textutils)

Запарил IBM... Сначала это все в рекламе, потом еще и в виде новестей?

Не нравится - не читай.

млин, я-то думал будет развернутый туториал на русском :( а тут опять "читайте маны...." втопку

А где эти самые советы? о_О

Ну и где что? Могли просто написать RTFM, то же самое получилось бы..

ужас

А тебе нравится? Я не понимаю политики.. То подобные новости удаляет Шаман, по-моему, с причиной "Было в рекламе"... То их подтверждают. Из этого даже флейма не получится :)

А гду статья с советами. Вся суть написанного абсолютно полностью передается заголовком (который, кстати, звучит "Полезный совет: Ознакомьтесь с текстовыми утилитами (textutils)"), далше читать нечего.

Фтопку такие новости, ибо на dW бывают намного лучшие статьи.

берется perl (например) и пишется все что нужно
это проще чем мучиться с текстовыми утилитами
пока задача не сильно сложна - ими можно пользоваться,
но как только шаг влево - шаг вправо, тут же оказывается что нужно писать сложный скрипт на sh или уже без awk не обойтись, а там уже и до perl рукой подать. так проще сразу на perl написать ...

На новость не тянет

Круто. Статья состоящая на 98% из воды, такого я еще не видел.

Читать умеем?

Подзаголовок: "Введение в серию полезных советов по автоматической обработке текста в Linux"

>Из этого даже флейма не получится :)

Обидно даже

Радовались бы, что маны пишут.

чет ниче полезного по ссылке не нашел

это тонкий пеар IBM?

>Серия полезных советов.

Серия первая.

>То подобные новости удаляет Шаман, по-моему, с причиной "Было в рекламе"...

имхо правильно делает

Да, давайте лучше посмотрим поближе как работают эти замечательные утилиты, которые уже давно не называются textutils, а называются GNU coreutils:

$ locale
LANG=ru_RU.UTF-8
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=
$ echo ЛАЛА|tr ЛА LA
AAAAAAAA
$ echo ПРЕВЕД|tr ПРЕВД PREVD
DRDVDDDDDDDD

Вывод: в линупсе все через задницу :)

Теперь получится(см предыдущий пост) :)

LFS:test@~:echo ПРЕВЕД|tr ПРЕВД PREVD
PREVED
LFS:test@~:locale
LANG=
LC_CTYPE=ru_RU.KOI8-R
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
LFS:test@~:

имхо тоже.. А то вылез какой-то товарищ, которого пару лет видно не было и давай подтверждать все направо и налево :)

Один из телепатов вернулся из отпуска?

Я конечно извиняюсь, но:

[fc7 ~]$ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
[fc7 ~]$ echo ÄÖÜ|tr Ü U
U�U�UU

> $ echo ПРЕВЕД|tr ПРЕВД PREVD
> DRDVDDDDDDDD
> Вывод: в линупсе все через задницу :)

смотря в каком линуксе: http://heirloom.sourceforge.net/tools.html :)

Это однобайтовый KOI а там был мультибайтовый UTF8, который сейчас практически во всех дистрибутивах по дефолту. И это правильно ибо Unicode наше фсио а однобайтовый зоорпарк из koi, cp1251 и cp866 - маст дай.

Любопытен каммент в исходнике этого пропиетарного поделия: когда tr используется для юникодных строк, он может запросто отъедать по 4М, а то и по 10 метров памяти, в то время как для однобайтных -- считанные килобайты. http://heirloom.cvs.sourceforge.net/heirloom/heirloom/tr/tr.c?revision=1.10&a...

а то люди всё удивляются, почему с ростом производительности железа, софт становится все более тормозным и требовательным к ресурсам? =)

Да практически в каждом GNU/Linux который с GNU coreutils(textutils) и локалью UTF8

> а то люди всё удивляются, почему с ростом производительности железа, софт становится все более тормозным и требовательным к ресурсам? =)

Да, ты прав. Вот смотри как проявляет себя сговор линуксоидов с производителями железа.

$ mount |grep /tmpfs
none on /tmpfs type tmpfs (rw,size=100M)
$ tar -C /tmpfs -xf /usr/portage/distfiles/linux-2.6.21.tar.bz2
...

$ time LANG=ru_RU.KOI8-R grep -r preved /tmpfs/

real 0m0.343s
user 0m0.131s
sys 0m0.174s
$ time LANG=ru_RU.UTF-8 grep -r preved /tmpfs/

real 0m6.662s
user 0m6.459s
sys 0m0.188s


Раскрыт тайный заговор линуксятников и железячников таких как IBM! Они пропатчили grep, так что если grep детектирует что у юзера система новая, с локалью UTF-8, то замедляет свою работу на порядки, чтобы несчастные юзеры покупали все более мощное железо!

Статья ни о чем.

Против IBM конечно ничего против не имею, но блин, такая открытая реклама, а тут даже завуалированная под новость.. AdWords были бы не так назойливы.. фу, противно. Новость откровенно ниочем еще и от чувака с таким ником

>Статья ни о чем.

+1

> и от чувака с таким ником

А этот пользователь только для новостей от IBM и создан :) Насколько я могу судить.

Так оно и есть :) Хотя пару раз были замечены комменты от него...

Точно, давайте вместо того, чтобы новички изучали основы шелла на русском языке, заставим их изучать берил и будем флудить про то что круче - гном или кде и обсуждать что еще умного сморозит наше правителсьство насчет подедржки опенсорс?

s/должны/можете/g

Запускать каждую команду надо 4 раза, первый результат отбрасывать - ибо кеширование, из остальных трёх считать среднее...

> Запускать каждую команду надо 4 раза, первый результат отбрасывать - ибо кеширование, из остальных трёх считать среднее...

Ыыы кеширование... Там /tmpfs в ОЗУ находится. К томуже запуск с UTF8-локалью был выполнен после запуска с однойбайтовой локалью KOI8-R. Это все заговор железячников с линуксоидами, я точно говорю!

>а тут опять "читайте маны...." втопку

Кстати, дельный совет. Я теперь даже если в винде что нибудь ставлю/настраиваю читаю мануал. Много времени экономит.

Извиняюсь, может ты прав, а может просто у кодописателей руки кривые...

Распаковал
# tar -xjf /usr/portage/distfiles/linux-2.6.22.tar.bz2
в /dev/shm ( shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev) )
и
# time -p LANG="ru_RU.UTF-8" grep -r preved .
real 22.66
# time -p LANG="C" grep -r preved .
real 0.69

Вобщем, несмешно =(

Убойный перевод почитал я.

Какая-то "водянистая" статейка...

> Извиняюсь, может ты прав, а может просто у кодописателей руки кривые...

Да не я пошутил. :) Просто алгоритм работы с мультибайтовыми строками(UTF-8) неоптимальный, он никогда не будет таким же быстрым как для однобайтовых строк, потому что длина одного символа в мультибайтовых кодировка епостоянна, а это большой гимор, поскольку ни длину строки в символах(strlen) ни извлечь i-й символ непросто. Как вариант - преобразование UTF-8 строки в UCS-2, но все эти преобразования туда-обратно также создают оверхед.

Вообще-то, это всего лишь введение в цикл статей. Что вы хотели от "введения"?

>Просто алгоритм работы с мультибайтовыми строками(UTF-8) неоптимальный, он никогда не будет таким же быстрым как для однобайтовых строк, потому что длина одного символа в мультибайтовых кодировка епостоянна, а это большой гимор, поскольку ни длину строки в символах(strlen) ни извлечь i-й символ непросто. Как вариант - преобразование UTF-8 строки в UCS-2, но все эти преобразования туда-обратно также создают оверхед.

Вот поэтому то хранить текст можно в UTF-8, а работать внутри программ с 8*n-битными символами...

>Вообще-то, это всего лишь введение в цикл статей. Что вы хотели от "введения"?

А что какое-то введение делает на ЛОРе? Впрочем, чему тут удивляться...

> Как вариант - преобразование UTF-8 строки в UCS-2

Это не вариант. Вопрос на засыпку. Сколько символов в Уникоде?

anonymous@localhost ~/tmp/heirloom-070715/tr $ echo ПРЕВЕД|./tr ПРЕВД PREVD PREVED

anonymous@localhost ~/tmp/heirloom-070715/grep $ time -p LANG=ru_RU.UTF-8 ./grep -r preved /dev/shm/ real 1.89 user 1.47 sys 0.41

anonymous@localhost ~/tmp/heirloom-070715/grep $ time -p LANG=C ./grep -r preved /dev/shm/ real 1.67 user 1.27 sys 0.39

Во блин! И почему, интересно, эти нормальные утилиты до сих пор не используются в дистрибутивах, а вместо них в дисрибутивы положены всякие тормозные ГНУтые и кривые как винда coreutils(textutils)?

anonymous@localhost ~/tmp/heirloom-070715/tr $ echo ПРЕВЕД|./tr ПРЕВД PREVD
PREVED

anonymous@localhost ~/tmp/heirloom-070715/grep $ time -p LANG=ru_RU.UTF-8 ./grep -r preved /dev/shm/
real 1.89
user 1.47
sys 0.41

anonymous@localhost ~/tmp/heirloom-070715/grep $ time -p LANG=C ./grep -r preved /dev/shm/
real 1.67
user 1.27
sys 0.39

Во блин! И почему, интересно, эти нормальные утилиты до сих пор не используются в дистрибутивах, а вместо них в дисрибутивы положены всякие тормозные ГНУтые и кривые как винда coreutils(textutils)?

> Это не вариант. Вопрос на засыпку. Сколько символов в Уникоде?

Отвечает капитан команды знатоков г-н Гугль Википедов:

"Поскольку в UTF-16 можно отобразить только 2^20+2^16 (1 114 112) символов, то это и было выбрано в качестве окончательной величины кодового пространства Юникода."

> Это не вариант. Вопрос на засыпку. Сколько символов в Уникоде?

Хорошо пусть будет UCS-4 под который идеально подходит типа wchar_t.