Ну в инет мну почему-то не пустили, какая-то хрень с провайдером, звонить мне ему лениво, потому я лучше посмотрю, что у нас появилось нового в sed, а то даже в последней Slackware 13.0 (хотя на днях и вышла 13.1, но я её ещё не поставил) версия всего-лишь 4.1.5.

Первое, что бросилось в глаза - изменилось описание моего любимого бага, а именно теперь рекомендуют для очистки буфера использовать не команду s/.*//, а команду z. Ну или как раньше: изменить значение системных переменных.

Так-же сменилась лицензия на третью версию.

> 2009-01-05  Paolo Bonzini  <bonzini@gnu.org>
> 
>         * execute.c (read_pattern_space): Reset hold space at end-of-file
> 	if input->reset_at_next_file.
>
			

Вот оно как! Это я что-то не понял, раньше что-ли область удержания НЕ очищалась после каждого файла?! Чего только не вычитаешь в чейнджлоге... Я думал - она ВСЕГДА очищается перед каждым новым файлом...

Чё-то намутили опять с POSIX MODE, впрочем - мне это не очень важно, я его не использую. Надеюсь лучшее соответствие стандарту пригодится тем, кто этот стандарт соблюдает. Меня стандарт не устраивает тем, что там слишком мало опций, а на всех МОИХ системах работает версия GNU, потому меня это не сильно взволновало...

А вот это уже интереснее:

> 2008-09-29  Paolo Bonzini  <bonzini@gnu.org>
> 
> 	* BUGS: Document s/.*.// behavior with invalid multibyte sequences.
> 	* NEWS: Document `z' extension.
>

Исправили поведение в случае НЕСИМВОЛОВ, если используется такой хитрый шаблон. Отлично. Хорошо, что я обновился. Это довольно опасная дыра. Впрочем, я ещё в коде пошукаю, мож там что-то более интересное. Ну и, как я уже неоднократно писал, добавили z.

А, ещё тест новый добавили - с несимволом. Надо бы проверить, как теперь моя "уязвимость" работает... Вот щаз и проверю...

Проверил - как и следовало ожидать - "уязвимость" осталась. Ну хорошо, что всё работает именно так, как я этого ожидал. Видимо в каких-то случаях sed тут выкидывала неожиданности. Что-ж, на сервере sed я уже давно обновил, ещё в том году. Что и вам рекомендую. (даже если вы терпеть не можете sed, то в ВАШИХ системах она всё равно используется. Можете проверить сами.)

> * new option --follow-symlinks, вот, новая опция появилась. Она действует вместе с редактированием "на месте", т.е. в том случае, когда файл идёт в поток, а потом, после редактирования, он возвращается обратно в файл. Очень любопытно, как в таком случае будет проходить редактирование, если права на каталог с симлинком RO? Это зависит от того, где sed создаст свой временный файл, если она задумает создать его там-же, где симлинк... Впрочем, пойду проверю.

Ага. В прошлой версии имеется баг: при попытке отредактировать симлинк sed 4.1.5 создаёт временный файл там где симлинк, и после редактирования убивает симлинк, и ставит на его место временный файл.

Новая версия ведёт себя точно так-же. Это без опции --follow-symlinks. А вот с опцией поведение именно такое, как и ожидается: действия производятся именно над файлом, а не над симлинком.

Вот. А ещё чё-то я не понял совсем фразы о том, что дескать опцию --follow-symlinks нельзя юзать обычным юзверям. А дескать, в будущем доделают. Вот только я не очень понял, чем это всё грозит простым юзерам, да и вообще системе в целом. Вот убейте - не догоняю... Сам я эту опцию поюзал, и она вроде нормально работает. Именно так, как я и ожидал - например я отредактировал файл рута, и этот файл сохранил свои права (444, только чтение), но сменил хозяина и временнЫе метки. Впрочем, я так-же делал и напрямую, а не через симлинк. Если у рута хватит мозгов закрыть от меня каталог где файл (*НЕ* симлинк!), то я с этим файлом ничего и не смогу сделать - начнём с того, что я не смогу создать там временный файл. Впрочем...

Неа, думал, что через симлинки можно атаковать каталоги, на которые установлен атрибут AppendOnly. Неа, что через симлинки, что просто так получается фигня: Временный файл создаётся. Однако, в этот файл невозможно ничего записать! Мало того, не работает команда копирования. А вот команда переноса - работает. Смешные каталоги. Ну а раз нельзя менять файлы в таком каталоге, то и удалить такой файл невозможно. Не каталог, а ловушка - если туда файл попал, то он там как муха в янтаре вязнет, и никто не может их удалить или изменить (даже рут), но вот отправить туда файл может кто угодно. Видимо такие каталоги удобно делать для бекапов и бекапов логов, кто угодно может туда отправить, но вот изменить там ничего не возможно. Причём, что самое интересное - с другого раздела тоже не перенести. Действительно, операция mv с раздела на раздел работает как cp src dest; rm src, а вот внутри раздела - ln src dest; rm src. Так-же можно сделать жёсткую ссылку на файл внутри защищённого каталога.