Если вы просто должны изменить это сценарий, но не можете изменить его, чтобы принять параметр командной строки для некоторых странная причина, вы можете попробовать следующее:
new_val=5000
sed -e "s/\$input_store_nbr = \"[0-9]+\";/\$input_store_nbr = \"$new_val\";/" src_file > tmp_file
mv tmp_file src_file
или если у вас есть sed
, который его поддерживает (например, GNU или BSD с аргументом), вы можете использовать флаг -i
для sed
и не требует (явного) временного файла.
Я все же думаю, что вам лучше один раз изменить исходный скрипт (поскольку вы уже изменяете его), чтобы сделать что-то вроде:
$input_store_nbr = $ARGV[0];
, а затем вызвать его с новым номером в качестве первого аргумента командной строки, как вы передал бы скрипту sed
для перезаписи файла.
automate it with bash scripts during boot time
автоматизировать... да, но не во время загрузки? После обновления ядра необходимо перезагрузиться. А раньше - выключение. Поэтому вы должны знать, когда это произойдет. Или я что-то упускаю. Подготовьте этот сценарий для компиляции этого переключателя ()с помощью одной команды, но не во время первой загрузки нового ядра.
Точно так же, как о модулях нужно позаботиться (с помощью make direct, с помощью дистрибутива, из которого вы также получаете новый initrd ), если у вас есть что-то, зависящее от версии ядра, например ваши драйверы, это относится к контрольный список, а не в загрузочный скрипт. В противном случае слишком велик риск n.a.i.w. (= не всегда работает:-)
uname -r
упоминалось... но хранить это в файле и проверять?
Местом для размещения информации и управления драйвером версии ядра -может быть сценарий загрузки. Через несколько месяцев это может выглядеть так
# 4.1.0 dispdr=firstone
# 4.2.0 dispdr=second_driver
# 4.4.0
dispdr=third
# next version probably 4.6.0
Это прозрачно и обратимо. Я ничего не знаю об этих драйверах, очевидно.
На общий вопрос :"как что-то сделать в случае изменения ядра" я с вами согласен и тоже сделаю что-то вроде:
program=my_system_version_checker
state_file=/var/lib/${program}/version
if [ -r "$state_file" ]; then
last_version=$( cat "$state_file" )
else
last_version="unknown"
fi
current_version=$(uname -r) # or may be uname -a or anything else you'd like
if [ $? -ne 0 ]; then
exit 1 # Handle case when we can't get current_version for some reason
fi
if [ "$last_version" != "${current_version}"]; then
make LAST_VERSION="$last_version" CURRENT_VERSION=${current_version} -C /opt/${program} update
fi
[ -d $(dirname $state_file) ] || mkdir -p $(dirname $state_file)
echo "$current_version" > "$state_file"
и поместите его в сценарии запуска для запуска при каждой загрузке (с файлом модуля systemd или выскочкой или чем-либо еще, в зависимости от вашей системы и диспетчера запуска ).
Но что касается пересборки модулей ядра таким образом, я не думаю, что это хорошая идея, так как вы можете сломать что-то с новыми драйверами и вы узнаете об этом при следующей загрузке, или вы можете добавить rmmod/insmod
логику в свой скрипт, который также может быть небезопасным для запуска. Поэтому я бы лучше использовал некоторые хуки, подобные DPkg::Post-Invoke
для apt
, чтобы запускать мой скрипт после обновления ядра.