Hi all,
I've been scripting now for coming up to a year and I am now managing several Mikrotik devices. To simplify management, I am re-writing scripts and improving them, with a view that only a handful of variables need updating at the top of the script for each location, and the rest can be left as is.
There are a few scenarios where I have to persistently store information in a Global Variable, like an interface IP address. The problem comes when I have several copies of the same script running simultaneously (E.G for several interfaces). The Global Variables then clash if they are not individually named manually.
Is there anyway I can have unique global variables per script?
Any ideas are appreciated.
-
-
boen_robot
Forum Guru
- Posts: 2400
- Joined:
- Location: europe://Bulgaria/Plovdiv
Re: Unique Global Variables
AFAIK, no... Other than, obviously, that you prefix the name with the value of another variable (e.g. the interface name) upon declaration.
To make this easier on yourself, you should pack your scripts into a function variable (you know... the "do" argument on ":global"...), and then use that function. The function itself will "install" each instance, i.e. declare the per-script global variables, their initial values, and perhaps add itself to scheduler if needed to keep them updated.
BTW, if you end up making some "general purpose" scripts (i.e. ones that let a user define their own settings, rather than use your hardcoded ones), abstracted away as functions, I'm sure many people (myself included) would like to check them out, so if you could share, that would be awesome.
To make this easier on yourself, you should pack your scripts into a function variable (you know... the "do" argument on ":global"...), and then use that function. The function itself will "install" each instance, i.e. declare the per-script global variables, their initial values, and perhaps add itself to scheduler if needed to keep them updated.
BTW, if you end up making some "general purpose" scripts (i.e. ones that let a user define their own settings, rather than use your hardcoded ones), abstracted away as functions, I'm sure many people (myself included) would like to check them out, so if you could share, that would be awesome.
Re: Unique Global Variables
Thats the method I am using at the moment.AFAIK, no... Other than, obviously, that you prefix the name with the value of another variable (e.g. the interface name) upon declaration.
I dont quite understand sorry. Do you mean a script to 'install' the script?To make this easier on yourself, you should pack your scripts into a function variable (you know... the "do" argument on ":global"...), and then use that function. The function itself will "install" each instance, i.e. declare the per-script global variables, their initial values, and perhaps add itself to scheduler if needed to keep them updated.
Thanks for your input
Re: Unique Global Variables
If the variables is only used within a script, they should be declared local and not global.
Re: Unique Global Variables
The variables need to be stored persistently, I.E if the script is run again, the variables are still there. Local variables only apply in that instance the script is ran.If the variables is only used within a script, they should be declared local and not global.
-
-
boen_robot
Forum Guru
- Posts: 2400
- Joined:
- Location: europe://Bulgaria/Plovdiv
Re: Unique Global Variables
Yes.I dont quite understand sorry. Do you mean a script to 'install' the script?To make this easier on yourself, you should pack your scripts into a function variable (you know... the "do" argument on ":global"...), and then use that function. The function itself will "install" each instance, i.e. declare the per-script global variables, their initial values, and perhaps add itself to scheduler if needed to keep them updated.
The idea is that you won't have to "manually" enter new global variables for each copy of the script, but you'll instead run the script with parameters. The parameters will determine the variables to be added, and add a copy of the script that would use those variables.
So for example,
Code: Select all
$installMonitor interface=localCode: Select all
$installMonitor interface=wan1-
-
dissident76
just joined
- Posts: 10
- Joined:
Re: Unique Global Variables
Hi robot,Yes.I dont quite understand sorry. Do you mean a script to 'install' the script?To make this easier on yourself, you should pack your scripts into a function variable (you know... the "do" argument on ":global"...), and then use that function. The function itself will "install" each instance, i.e. declare the per-script global variables, their initial values, and perhaps add itself to scheduler if needed to keep them updated.
The idea is that you won't have to "manually" enter new global variables for each copy of the script, but you'll instead run the script with parameters. The parameters will determine the variables to be added, and add a copy of the script that would use those variables.
So for example,Would read the "interface" argument, and create a global variable with the name "monitor_local_ip" for the IP address of the interface "local", and so on. If you want the same script for another interface, you run your install script with the name of the new interface, soCode: Select all$installMonitor interface=localto now create the "monitor_wan1_ip" variable, etc.Code: Select all$installMonitor interface=wan1
That is exactly the idea I was looking for, but what's the syntax to use the value of a parameter (or variable) as variable name?
I have tried this and it does not work:
:global name wan1;
:global $name
If this worked, I would have declared a variable named "wan1", which is the value of $name (or any parameter, like $1, etc)
Thanks a lot
Re: Unique Global Variables
Dirty way to have system-wide, persistent variable even after reboot: use something like a comment on an interface.
Code: Select all
/interface ethernet set ether1 comment=$myDataCode: Select all
:local myData [/interface ethernet get ether1 comment ];-
-
boen_robot
Forum Guru
- Posts: 2400
- Joined:
- Location: europe://Bulgaria/Plovdiv
Re: Unique Global Variables
Drat... I thought that the syntax would be
(with the "name=" and quotes being a way to disambiguate between that and a new global variable called "interface")
But that doesn't work... The only way seems to be to call :execute with appropriate arguments, which BTW means the installer can be easily broken when a value is supplied that would spill into the rest of the script (probably causing a had to detect error).
So f.e.
would create a global variable with a name equal to "interface_", followed by the interface name, and with a value equal to "val". If $interface had a value of "local", the variable can then be referenced with $"interface_local".
Code: Select all
:global name="$interface" "value";But that doesn't work... The only way seems to be to call :execute with appropriate arguments, which BTW means the installer can be easily broken when a value is supplied that would spill into the rest of the script (probably causing a had to detect error).
So f.e.
Code: Select all
:execute script=":global \"interface_$interface\" \"val\""-
-
dissident76
just joined
- Posts: 10
- Joined:
Re: Unique Global Variables
Yeah, that worked, thanks a lotDrat... I thought that the syntax would be(with the "name=" and quotes being a way to disambiguate between that and a new global variable called "interface")Code: Select all:global name="$interface" "value";
But that doesn't work... The only way seems to be to call :execute with appropriate arguments, which BTW means the installer can be easily broken when a value is supplied that would spill into the rest of the script (probably causing a had to detect error).
So f.e.would create a global variable with a name equal to "interface_", followed by the interface name, and with a value equal to "val". If $interface had a value of "local", the variable can then be referenced with $"interface_local".Code: Select all:execute script=":global \"interface_$interface\" \"val\""
