Спустя почти восемь лет с момента выпуска ветки 4.2 сформирован (http://www.mail-archive.com/info-gnu@gnu.org/msg02225.html) релиз утилиты GNU sed 4.3 (http://www.gnu.org/software/sed/), в рамках которой развивается реализация не интерактивного текстового редактора, обычно применяемого для создания фильтров, модификации текстовых файлов и замены блоков по шаблону.
Ключевым улучшением новой версии является значительное ускорение операций сопоставления по регулярным выражениям, которые теперь выполняются быстрее в 10 раз. Кроме того, по возможности отныне применяется неблокирующий ввод/вывод, что также положительно сказывается на производительности. Из новой функциональности отмечается появление опции "--sandbox", при указании которой блокируется выполнение команд "r", "w" и "e".URL: http://www.mail-archive.com/info-gnu@gnu.org/msg02225.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=45815
Как все слова выстроить в столбик?
echo "Ключевым улучшением новой версии является" | sed "s/ /\n/g"
Немного улучшил.
echo "Ключевым улучшением новой версии является" | sed -r 's/\s+/\n/g'
теперь> OpenNews: Шахматы, реализованные с использованием утилиты sed
будут работать в 10 раз быстрее? ура!
Только ради них все и затевалось. Ждем еще лет 5 пока GPU ускорение завезут, вот там заживем.
Эти шахматы в оригинале заточены под юникод и при однобайтных локалях не работают. Однако, я на коленке портанул под локаль KOI8-R: gopher://sdf.org/9/users/saahriktu/filez/notbyme/SedChess.tar.xz .
А что это за гопхер? o_O
curl gopher://sdf.org/9/users/saahriktu/filez/notbyme/SedChess.tar.xz > SedChess.tar.xzПользуясь случаем хочу спросить, это так и задумано, у меня всё работает правильно?
В ядерной консоли с локалью KOI8-R оно взлетает так: http://saahriktu.org/tmp/scr1483608023.png
Пропатчил цвета для ядерной консоли: http://saahriktu.org/tmp/scr1483611819.png
>> Малыш
> Саш, ты неправ.Прав, потому как я не про физический возраст.
http://linuxmd.net/forum/komandnaya-stroka-terminal/276-prot...
> А что это за гопхер?saahriktu — известный тролль на тему экзотических локалей и протоколов
>экзотических локалейМежду прочим, в исходниках 5-го Perl'а до сих пор написано "KOI8 - De Facto Standard for the Cyrillic world". В исходниках ядра Linux и версии 4.9 написано "KOI8-R is preferred in Russia". А на официальном сайте юникода есть файл http://unicode.org/Public/MAPPINGS/VENDORS/MISC/KOI8-R.TXT , обновление которого датировано 2016-01-04 23:05:00 GMT [KW].
Просто КОИ8 всем настолько нужна, что о ней забыли удалить упоминания.
А вот и нет. Я упомянул только про вершину айсберга. Тот же INABA Hitoshi активно пилит модуль Char-KOI8R для 5-го Perl'а. Модуль отучает Perl от отдельных случаев интерпретирования текста в KOI8-R как бинарных данных и автоматически устанавливает кодировку скрипта в KOI8-R. Последняя версия вышла в конце августа. В этой версии автор по просьбам портанул модуль и на Win 10. В винде, напоминаю, выставить локаль KOI8-R в эмуляторе терминала можно командой "chcp 20866".
А чем KOI8-R лучше Юникода?
Архитектурной простотой, надёжностью и предсказуемостью. Юникодные парсеры постоянно ломаются на "некорректных данных". А для однобайтных парсеров KOI8-R "некорректных данных" просто не бывает. Они и юникод на отдельные байты разберут, включая некорректные для юникодных парсеров данные. Ну и т.д.
> Юникодные парсеры постоянно
> ломаются на "некорректных данных".Странно, ни разу не видел. А можно примерчик?
> просто не бывает. Они и юникод на отдельные байты разберут, включая
> некорректные для юникодных парсеров данные.А зачем это может понадобиться? Там же нечитаемые кракозябры будут в таком случае?
http://www.linux.org.ru/forum/talks/13057674 . Ещё при локали UTF-8 файлы с некорректными для UTF-8 именами могут исчезать из файловых менеджеров, но внезапно появляться при локали KOI8-R. Кракозябрами имена файлов или нет - не так важно относительно того отображаются ли оно вообще или нет. Если они отображаются - можно и переименовать.
> http://www.linux.org.ru/forum/talks/13057674 .У меня должен был браузер упасть? В заголовке квадратик.
Вообще, там человек знатный ССЗБ. А можно это вызвать как-то попроще? :)> Ещё при локали UTF-8 файлы с некорректными
> для UTF-8 именами могут исчезать из файловых менеджеров, но внезапно появляться
> при локали KOI8-R. Кракозябрами имена файлов или нет - не так
> важно относительно того отображаются ли оно вообще или нет. Если они
> отображаются - можно и переименовать.А где такие файлы взять?
Какие-то надуманные примеры, если честно. Можно (может и нельзя, я не проверял) еще сделать файлы с очень длинными именами, чтобы кончалась память/было переполнение. Но зачем?..
Самый простой способ поломать юникодный парсер - скормить ему текст в любой однобайтной кодировке. Мне по этой причине пришлось патчить pip из состава Python'а 3.6.0. А то выпадал в осадок при сборке с ошибкой "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcb in position 22: invalid continuation byte" (авторы жёстко прописали дефолт в UTF-8; а суть патча свелась к "sed -i "s/'utf-8'/'koi8-r'/g" pip/_vendor/distro.py").Соответственно, часть файлов, имена которых в KOI8-R, может пропадать при локали UTF-8. Но, ни один файл с именем в UTF-8 не пропадёт при локали KOI8-R.
Ситуации бывают разные. Вот, например, у меня имена файлов в KOI8-R, а на какой-то другой машине локаль UTF-8. Что будет если я перекину файлы на флэшку, которую подключу к другой машине? Правильно, часть файлов я вообще не увижу. Даже кракозябрами.
> Ситуации бывают разные. Вот, например, у меня имена файлов в KOI8-R, а
> на какой-то другой машине локаль UTF-8. Что будет если я перекину
> файлы на флэшку, которую подключу к другой машине? Правильно, часть файлов
> я вообще не увижу. Даже кракозябрами.Если у вас имена файлов тоже будут в UTF-8, то проблемы не будет в принципе. Зачем изобретать себе сложности?
Это если они будут в валидном UTF-8. Мало ли откуда могут появиться файлы с невалидными именами. Через те же торренты (мало ли что там в раздачах), уязвимости (хорошая идея - прописать вирусятину в системе через файлы с невалидными UTF-8 именами),... и т.д. И они будут, но не будут видны.
> Это если они будут в валидном UTF-8. Мало ли откуда могут появиться
> файлы с невалидными именами. Через те же торренты (мало ли что
> там в раздачах), уязвимости (хорошая идея - прописать вирусятину в системе
> через файлы с невалидными UTF-8 именами),... и т.д. И они будут,
> но не будут видны.И сколько раз вы с таким сталкивались?
> Самый простой способ поломать юникодный парсер - скормить ему текст в любой
> однобайтной кодировке. Мне по этой причине пришлось патчить pip из состава
> Python'а 3.6.0. А то выпадал в осадок при сборке с ошибкой
> "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcb in position 22: invalid
> continuation byte" (авторы жёстко прописали дефолт в UTF-8; а суть патча
> свелась к "sed -i "s/'utf-8'/'koi8-r'/g" pip/_vendor/distro.py").
> Соответственно, часть файлов, имена которых в KOI8-R, может пропадать при локали UTF-8.
> Но, ни один файл с именем в UTF-8 не пропадёт при
> локали KOI8-R.Хорошо. А зачем ему скармливать текст в однобайтовой кодировке?
Криворукость кодеров бывает разной. Некоторые, вон, вообще локаль не читают. А какие-то тексты и при юнокодной локали могут оказаться в однобайтной кодировке. Да и юникодный текст внезапно может побиться. И юникодный парсер его уже не распарсит.
> Криворукость кодеров бывает разной. Некоторые, вон, вообще локаль не читают.В таком случае текст обычно бывает как раз-таки в UTF-8. Или просто в ASCII.
> А какие-то
> тексты и при юнокодной локали могут оказаться в однобайтной кодировке. Да
> и юникодный текст внезапно может побиться.Если по какой-то причине начал портиться текст в рандомном месте, то там уже не до парсера.
Всякое бывает. Речь про проблемы в юникодных парсерах вообще. То, что они обычно работают как надо, не исключает связанных с ними проблем.
> Всякое бывает. Речь про проблемы в юникодных парсерах вообще. То, что они
> обычно работают как надо, не исключает связанных с ними проблем.Вы с этими проблемами часто сталкиваетесь? Я вот узнал об их существовании сегодня от вас.
Так у меня же локаль KOI8-R. Поэтому проблемы юникодных парсеров меня не касаются кроме тех случаев, когда по криворукости разработчиков они оказываются задействованы по дефолту. А вот на машине с локалью UTF-8 как-то наблюдал исчезающие файлы. Так что, про такие проблемы я знаю, но это проблемы параллельного мира юникодеров.
> Так у меня же локаль KOI8-R. Поэтому проблемы юникодных парсеров меня не
> касаются кроме тех случаев, когда по криворукости разработчиков они оказываются задействованы
> по дефолту. А вот на машине с локалью UTF-8 как-то наблюдал
> исчезающие файлы. Так что, про такие проблемы я знаю, но это
> проблемы параллельного мира юникодеров.Вот только сами "юникодеры" о проблемах почему-то не знают. :) А вы знаете.
Ну так однобайтного контента на котором ломаются юникодные парсеры у меня же больше, как я уже упомянул. Тот же pip из состава Python'а 3.6.0 вылетает при сборке именно на локали KOI8-R. А упомянутые выше шахматы на sed'е в оригинальном виде вылетают именно у юзеров локали KOI8-R. С ошибкой "sed: файл chess.sed строка 312: строки для команды `y' имеют разную длину". И т.д. Так что, многое из параллельного мира юникодеров более явно именно в нашем мире юзеров локали KOI8-R.
> Ну так однобайтного контента на котором ломаются юникодные парсеры у меня же
> больше, как я уже упомянул. Тот же pip из состава Python'а
> 3.6.0 вылетает при сборке именно на локали KOI8-R. А упомянутые выше
> шахматы на sed'е в оригинальном виде вылетают именно у юзеров локали
> KOI8-R. С ошибкой "sed: файл chess.sed строка 312: строки для команды
> `y' имеют разную длину". И т.д. Так что, многое из параллельного
> мира юникодеров более явно именно в нашем мире юзеров локали KOI8-R.Ну т.е. с KOI8-R проблем больше, чем с юникодом. Я правильно понимаю? :)
Собственно, из того, что вы назвали, серьезным можно назвать то, что можно подсунуть парсеру левую хрень, от которой он может упасть. Но тогда это ошибка конкретного парсера, которую надо исправлять. Например, пропуская символы (раз уж все равно там белиберда, то уже без разницы). Хотя я с таким, опять же, не сталкивался.
А это как посмотреть. Юзеры локали KOI8-R всё равно отказываются работать с юникодным софтом. Ведь то, что оно не взлетит, и так ожидаемо. Другой вопрос, что некоторые решают сразу за всех, и ставят юникод по дефолту. И даже не читают локаль. Нет бы прочитать локаль и выходить в нужных местах, если уж без жёсткого прописывания юникода никак. И вот тогда становятся видны спотыкания. А в остальном всё и так KOI8-R'ное и работает как часы.
> А это как посмотреть. Юзеры локали KOI8-R всё равно отказываются работать с
> юникодным софтом. Ведь то, что оно не взлетит, и так ожидаемо.
> Другой вопрос, что некоторые решают сразу за всех, и ставят юникод
> по дефолту. И даже не читают локаль. Нет бы прочитать локаль
> и выходить в нужных местах, если уж без жёсткого прописывания юникода
> никак. И вот тогда становятся видны спотыкания. А в остальном всё
> и так KOI8-R'ное и работает как часы.Не «решают за всех», а даже не думают об этом. Что совершенно ожидаемо, т.к. те, у кого юникод, обычно не думают о кодировках совсем. А зачем, если все само работает? :)
А что вы делаете, если нужно что-то, кроме кириллицы и латиницы? Например, греческие буквы.
Ситуации бывают разные. В том же telegram-cli разработчики сделали дефолтом именно UTF-8 без всяких альтернатив (а в случае других локалей перекодировать таки нужно). Я им писал в багтрекер, но ничего это не поменяло. Так что, даже если разработчики и не совсем забыли про другие локали это может мало что менять.В plaintext'е мне такое не нужно. Да и с форматированными документами я особо не сталкиваюсь. Кстати, у меня есть утилита для дампа данных из UTF-32 в KOI8-R: http://www.linux.org.ru/news/opensource/12982880 . Так что, распарсить юникодные тексты я спокойно могу и в кодировке KOI8-R.
> Ситуации бывают разные. В том же telegram-cli разработчики сделали дефолтом именно UTF-8
> без всяких альтернатив (а в случае других локалей перекодировать таки нужно).Полагаю, потому что писать вам будут именно в UTF-8 и разработчики не хотят возиться с кракозябрами?
Что должно произойти, если вам пришлют символы, которых в KOI8-R нет?
Их можно просто обрезать. Всё равно все юзеры KOI8-R согласились на "iconv -c". При обсуждении вопроса кто-то заявлял, что iconv() есть не на всех платформах. Ну так ./configure никто не отменял. В куче проектов есть отдельные платформозависимые куски кода, которые включаются в зависимости от платформы. Можно было хотя бы для Linux'а включить iconv() между сетью в UTF-8 и консолью в другой локали.
> А зачем ему скармливать текст в однобайтовой кодировке?(шёпотом) из РосКомСвязи ещё и не такое прилетает. Набор строк в одной таблице с разными кодировками (как им операторы налили, "nobody cares") и разбирай как хочешь.
>> А зачем ему скармливать текст в однобайтовой кодировке?
> (шёпотом) из РосКомСвязи ещё и не такое прилетает. Набор строк в одной
> таблице с разными кодировками (как им операторы налили, "nobody cares") и
> разбирай как хочешь.enca/librcd+librcc построчно?..
> enca/librcd+librcc построчно?..enca на сотнях тысяч строк (ABC & DEF)? Нет, я так не играю :)
А вот за (librcd+librcc) — спасибо, исторически там "сюрпризы" тупо катчатся и дальше в полуручном режиме.
>> Юникодные парсеры постоянно ломаются на "некорректных данных".
> Странно, ни разу не видел. А можно примерчик?Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз, например.
>>> Юникодные парсеры постоянно ломаются на "некорректных данных".
>> Странно, ни разу не видел. А можно примерчик?
> Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз, например.Мм, где? Если вы о том, о чем я думаю, то мне казалось, это ошибки OCR.
>>>> Юникодные парсеры постоянно ломаются на "некорректных данных".
>>> Странно, ни разу не видел. А можно примерчик?
>> Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз
> Мм, где? Если вы о том, о чем я думаю, то мне казалось, это ошибки OCR.Нет -- обычно в заголовках или автоматически сформированных цитатах.
> Нет -- обычно в заголовках или автоматически сформированных цитатах.А, на опеннете же. Да, точно, хороший пример.
Но вот проблема-то создана именно тем, что сайт использует KOI8-R. а пользователи вводят данные в UTF-8. :)
>> Нет -- обычно в заголовках или автоматически сформированных цитатах.
> А, на опеннете же. Да, точно, хороший пример.Именно что не здесь.
> Но вот проблема-то создана именно тем, что сайт использует KOI8-R. а пользователи
> вводят данные в UTF-8. :)Было сомнение по ходу обсуждения, а сейчас Вы прямым текстом расписались как в полном непонимании, так и в тяге к обсуждению из соображений вроде "чё это он не как все".
Вижу порой таких вот анонимных защитников "всего нового против всего старого", и всегда у них крупные проблемы с собственно пониманием, а не реагированием...
>>> Нет -- обычно в заголовках или автоматически сформированных цитатах.
>> А, на опеннете же. Да, точно, хороший пример.
> Именно что не здесь.Тогда я все-таки не понял, где. Можете все-таки ссылку дать?
>>>> Нет -- обычно в заголовках или автоматически сформированных цитатах.
>>> А, на опеннете же. Да, точно, хороший пример.
>> Именно что не здесь.
> Тогда я все-таки не понял, где. Можете все-таки ссылку дать?Не-а, не запоминал; а ради оппонента, допускающего такие ошибки и при этом упорно продолжающего дискуссию (т.е. явно гробящего избыток времени попусту) -- искать не стану, простите.
Характерный признак -- "убитый" в кракозябра последний символ строки перед каким-нибудь многоточием.
https://www.zabbix.com/forum/forumdisplay.php?f=21
Встречаются и обрезанные заголовки, и сообщения в разных кодировках одновременно, всякое там есть.
Вот очень древний пример: https://www.zabbix.com/forum/showthread.php?t=14476
>> Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз, например.
> Мм, где? Если вы о том, о чем я думаю, то мне казалось, это ошибки OCR.Ну например: при добавлении в базу решили обрезать введённую юзером в юникоде строку. Обрезали побайтно до 25 символов, потому что поле было такого размера. Затем извлекли из базы и куда-то вставили... и получили документ с битым юникодом.
>>>> Юникодные парсеры постоянно ломаются на "некорректных данных".
>>> Странно, ни разу не видел. А можно примерчик?
>> Сколько угодно попадается побайтно разорванных на полусимволе сокращённых фраз,
>> например.
> Мм, где?Например, в старой mediawiki при поиске можно огрести в отрывке вместо многоточия:
---
...никами <s>и собранный deb (он же переделан [[Elbrus/alien|alien]]'ом в rpm) glibc-2.21-20.005</s> и пакет из нег� BR: libgd2-devel временно отключено -- см. [[Elbrus/groff#libXt]] насчёт потери зависимостей между
---(а gd2 вчера допинал после сборки всего нужного питоньего хозяйства, следом и glibc пересобрал "по полной")
Скажите японцу, что KOI8-R - это вообще ни разу ни алафавит в России!
Вы решаете несуществующие проблемы с мертвой кодировкой. 2017 год на дворе, у вас что 16 битный компьютер?
Оппа, а что, есть ещё те, кто не перешёл на UTF-8 ?PS Сам не переходил, пока MC не стал нормально поддерживать UTF-8, но давно уж как научился.
> Оппа, а что, есть ещё те, кто не перешёл на UTF-8 ?Да, есть.
Отличная строчка для резюме:
Опытный пользователь. Обыгрываю текстовый редактор в шахматы.
Заставляю текстовой редактор играь шахматы
Годно!
"Быстрее в 10 раз"
Втф. Убрали из кода слипы?
> значительное ускорение операций ... в 10 разЭто отнюдь не мини-новость! В файрфоксе и за 50 версий такого нововведения не сыщешь.
>> значительное ускорение операций ... в 10 раз
>
> Это отнюдь не мини-новость! В файрфоксе и за 50 версий такого нововведения не сыщешь.sed 's|ускорение операций|потребление памяти|g' новость_о_sed.txt > новость_о_firefox.txt
>>> значительное ускорение операций ... в 10 раз
>>
>> Это отнюдь не мини-новость! В файрфоксе и за 50 версий такого нововведения не сыщешь.
> sed 's|ускорение операций|потребление памяти|g' новость_о_sed.txt
> > новость_о_firefox.txtУ меня Firefox потребляет память в 10 раз. Это плохо?
Следующая версия будет sedD для поддержки systemD ?
Сплюньте и помойте рот после таких заявлений!
