Чтобы сохранить значения переменных после перезагрузки.

Сожалею, но половина форума использует L7 как переменные. Если есть лучший способ, пожалуйста, выложите пример. И, кстати, подсчёт трафика LTE в качестве такой переменной должен быть встроен в ROS…

Как вообще хранить переменную в секции скрипта менее безумно, чем хранить ее в правиле l7? Можешь выложить пример? Почему бы просто не сохранять переменную после перезагрузки, если она хранится как глобальная?

Иногда тебе нужны переменные, которые сохраняются даже после перезагрузки. Например, скрипт, который перезагружается, если интернет-соединение потеряно или обнаручена определенная атака. Тебе нужно отслеживать количество перезагрузок, чтобы скрипт в конце концов перестал перезагружаться сам.

Нашел новый способ с помощью цепочек брандмауэра. Замени `variable_name` на настоящее имя твоей переменной, а `variable_value` — на его значение.

Чтобы создать новую переменную:
`/ip firewall filter add chain=variables comment=variable_name content=variable_value`

Чтобы прочитать значение переменной:
`:put [/ip firewall filter get [find chain=variables comment=variable_name] content]`

Чтобы обновить значение переменной:
`/ip firewall filter set [find chain=variables comment=variable_name] content new_value`

Чтобы удалить переменную:
`/ip firewall filter remove [find chain=variables comment=variable_name]`

Цепочка "variables" никогда не выполняется, избегает нагрузки на процессор. -RoddyZ

cmit: Думаю над твоей идеей скрипта, и создал следующий скрипт, чтобы воссоздать все глобальные переменные при старте, используя планировщик autoexec (вроде: http://forum.mikrotik.com//viewtopic.php?t=1611&highlight=autoexec). :foreach i in=[/ip firewall filter find chain=variables] do={ :log info ("Загрузка переменных: " . [/ip firewall filter get $i comment] . “=” . [/ip firewall filter get $i content] ) :global [/ip firewall filter get $i comment] [/ip firewall filter get $i content] } Но, лучше иметь более эффективный способ сохранения переменных. Команда MT, пожалуйста, обратите внимание… -RoddyZ

13 лет спустя. Ну, я написал функцию, которая читает и пишет постоянные переменные как layer7-протоколы:
:global persist do={

   :local varName $1
   :local varValue $2
   :local varID [/ip firewall layer7-protocol find name="$varName"]

   :if ([:typeof $varValue] = "nothing") do={
       :if ($varID != "") do={
           :set $varValue [/ip firewall layer7-protocol get $varID value-name=regexp]
       }
   } else={
       :if ($varID = "") do={
           /ip firewall layer7-protocol add name="$varName" regexp="$varValue"
       } else={
           /ip firewall layer7-protocol set $varID regexp="$varValue"
       }
   }

   return $varValue

} Примеры использования: (name = имя переменной, value = значение переменной) $persist name = Чтение постоянной переменной $persist name value = Запись постоянной переменной :global name [$persist name] = Чтение постоянной переменной и запись её в глобальную переменную :global name [$persist name value] = Запись данных в глобальную переменную и в постоянную переменную одновременно Заметки: Функция использует layer7-протоколы для хранения постоянных данных. Все данные, прочитанные из постоянного хранилища, будут строками. Функция всегда возвращает значение.

Но... что с быстрым выключением питания... данные будут потеряны! L7 сохраняет последнее известное значение при каждом перезапуске. Но... планировщик создаст ГЛОБАЛЬНУЮ переменную, чтобы другие скрипты могли её использовать. Лучше, если мы останемся с локальными переменными и не будем использовать слишком много глобальных. Каждый скрипт может создавать локальную или глобальную переменную при запуске, нам не нужны переменные без последнего значения из предыдущего перезапуска. Но... на уровне скриптов мы не можем отредактировать переменную=значение в одной строке кода события планировщика! Мы не можем экспортировать это в файл из только одного планировщика, мы не можем редактировать это через `sed&awk` — не работает здесь… у нас нет подходящего обходного пути… Layer7 – лучший вариант. Зачем запускать планировщик для создания глобальных переменных, которые будут читать последнее значение из NAND? Это ещё хуже, чем L7. Конечно, мы можем придумать что-нибудь более безумное, например, создать новую bridge-variable1, задать значение в команде, но всё равно, L7 лучше. Предложение на будущее:

Почему на свете RuterOS не сохраняет глобальные переменные после перезагрузки? Можете ли вы показать какой-нибудь другой язык скриптов или язык программирования, где определенные переменные волшебным образом восстанавливают свои значения из предыдущего экземпляра скрипта, не сохраняя данные в файл, реестр или базу данных? Если вы хотите сохранить что-то, обработайте это в своем коде. Но… что насчет внезапного отключения питания… данные будут потеряны! L7 запоминает только последнее значение при каждой перезагрузке. С L7 все как с конфигурацией планировщика: вам нужно записывать изменения. Если вы не запишете последние изменения в планировщик или даже в используемый вами L7, то, конечно, ничего не сохранится. Преимущество использования стартового планировщика в том, что вам не нужно читать и разбирать переменные, они просто загружаются автоматически при старте. Локальные переменные локальны области видимости, сохранять их не имеет смысла. Нет куда их восстанавливать, потому что область видимости не существует, когда скрипт завершен.

С L7 всё то же самое, что и с настройками планировщика: чтобы изменения вступили в силу, их нужно записать. Если вы не сохраняете последние изменения в планировщике или даже в используемом вами L7, то, конечно, ничего не сохранится. Преимущество использования стартового планировщика в том, что вам не нужно читать и парсить переменные – они просто автоматически загружаются при старте. Я понимаю вас, что бы там ни хранилось, постоянная среда – это известная вещь, и мы можем использовать её, например, через `setx /M path "%path%;C:\your\path\here\"`. Способ планировщика должен делать `scheduler-env-startup` – он создаёт глобальную переменную со значением по умолчанию. `scheduler-run-own-finall-app` – это изменит нашу глобальную переменную. `scheduler-env-udpate` – каждые x времени он берет все глобальные переменные и заменяет данные в `scheduler-env-startup`. Лучший способ — хранить эту переменную в `/flash/env.txt` и загружать/обновлять их из планировщиков, потому что редактировать тело другого скрипта/планировщика без `sed&awk` в ROS — не самая простая задача. Тем не менее, Layer7 работает настолько идеально, и мы используем это, благодаря всего одной строке кода, мы можем остаться локальными, что значит, это почти идеально. В реальности… часто обходные пути живут дольше, чем решение.