Удалить все строки в файле, идущие после заданной

sed '/шаблон/,$d' имя_файла

или

sed 'номер_строки,$d' имя_файла

#!/bin/bash

declare -i c=0

while true do

sed '/done/,$d' /etc/init.d/generator

c=$(( c + 1 )) echo «$c» >> /etc/init.d/generator

sleep 5 done

Строки, создаваемые после done, не удаляются. С номером строки тоже не вышло. Почему?

А права на запись в файл /etc/init.d/generator есть? От рута скрипт выполняешь?

А права на правку каталога /etc/init.d/ ?

Судя по тому, что строки создаются, предположу что с правами на запись все в порядке?

хиндустайл )))

grep -B999999 "содержание_строки" file

Непонятно, откуда должно взяться слово «done» в файле /etc/init.d/generator ?

И дополнительный вопрос: а почему все операции именно в /etc/init.d/ ? Не лучше ли сначала отладить скрипт в «песочнице» (где-нибудь в домашнем каталоге), а уж потом смело идти в общесистемный каталог?

по номеру строки

TMP=$(mktemp /tmp/my_cool_prog.XXXXXXX)
head -n N $1> $TMP
mv -f $TMP $1

А по содержанию таки sed'ом лучше.

Кстати по номерам строк можно было бы и так:

head -номер_последней_нужной_строки имя_файла

Я сейчас ещё раз проверил все предложенные мной варианты на нескольких файлах. Всё работает.

Скрипт постом выше это и есть generator, добавляющий сам в себя строки. Удалять он их тоже должен (все это не лишено смысла).

С grep -B999999 «done» /etc/init.d/generator тоже не работает.

А done у тебя именно так записан, как в комменте?

sleep 5 done

Именно так?

Надо done на отдельную строку вынести или точку с запятой поставить:

sleep 5; done

И всё-таки остаётся вопрос: зачем подобные эксперименты в общесистемном каталоге проводить? Да ещё не вполне уверенно чувствуя себя в шелле и его инструментах, как я понял.

head -17 /etc/init.d/generator так тоже не сработало. С правами все в порядке же? Цифры записываются в конец файла. chmod +w /etc/init.d/generator ls -l /etc/init.d/generator -rwxr-xr-x 1 root root 247 Янв 26 15:16 /etc/init.d/generator

done на отдельной строке, исковеркалось. На второй вопрос ответа нет - создавал где попалось. Разве могло повлиять?

А сообщения какие-нибудь выдаёт? Или молча ничего не делает?

М-да, неотлаженные скрипты напускать на системные каталоги — это более чем смело. Я бы так не решился.

Разве могло повлиять?

Теоретически — нет. Но на практике всякое случается.

Я скрипт скопировал, но перед запуском стал внимательно смотреть, и нихрена не понял, что он должен делать. Задача абсолютно непонятна. Зачем весь этот гемор? Цель какая?

/* Вообще-то, прежде чем отвечать, я должен был сразу этот вопрос задать, а не ковырять не-пойми-что. :) */

По-моему, это называется "серп → яйца".

Вот я и смотрю: то ли человек шелл только ещё осваивает, но сразу хватается за какие-то непонятные головоломки, то ли какой-то «вирус» пытается сварганить, и истинную цель скрывает. :)

Мне вот абсолютно непонятна практическая цель этих извратов с самокастрированием, да ещё и в динамике, да ещё и в системном каталоге.

Пытается изобрести форк патча Бармина: "патч Цеврио".

Меня спас ключ -i, цель была изменять файл. Выходит, по неопытности я не правильно сформулировал задачу.

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

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

Для этого есть нормальный инструмент — inotify. И никаких геморных костылей не нужно.

Вот не зря же постоянно твердят: правильная формулировка и постановка задачи даёт половину её решения. :)

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

Можно подробнее, как http://ru.wikipedia.org/wiki/Inotify сможет в этом помочь? На сколько я понял из вики, он занимается чем то более сложным, чем генерация файлов. Я правильно думаю, что он способен принудить ПО обращаться к конфигу?

Наоборот, inotify занимается совсем простым делом: отслеживает изменения файлов и/или каталогов и выдаёт соответствующее оповещение. А ты описываешь реакцию на это оповещение, скажем, тем же скриптом.

То есть, ты пишешь скрипт (или программу, без разницы), который запускается по сигналу от inotify и вносит нужные изменения в конфиг или ещё куда. Вот и вся механика.

Кстати, именно для скриптов есть утилитки inotifywait и inotifywatch (как пакет называется, навскидку не вспомню). Все проблемы отслеживания изменений файлов/каталогов решаются без труда.

Возможно у меня не самая стандартная ситуация - сам конфиг не меняется, но меняется значение IP в ddns хостах, прописанных в нем - необходимо чтобы ПО оборащалось к конфигу и таким образом обновляло в себе информацию об актуальных IP.

«То есть, ты пишешь скрипт (или программу, без разницы), который запускается по сигналу от inotify и вносит нужные изменения в конфиг или ещё куда. Вот и вся механика.»

Тогда возможен такой вариант - написание скрипта, берущего IP на интерфейсах ppp0 ppp1 ppp2 и т.д. и отправляющего их в нужный конфиг ПО, а inotify будет запускать этот скрипт, в случае если адреса поменяются?

Но с другой стороны очередной костыль, уже второй после скрипта. Я хотел обойтись только скриптом, просто заставить ПО каждые 5-10 секунд обращаться к своему конфигу. Можно было бы без интервалов, а с проверкой смены адреса на интерфейсе, но ddns хосты могут обновляться несколько минут - inotify сможет проверять в них значение IP?

Если ПО остлеживает изменение по дате последнего изменения файла, то man touch.