Writing a script in Scheduler.

RouterOS Scripting
1

With ros 7.6 I tried to write a script directly in Scheduler and this works.
I ask is it correct to do this or what problems might it bring?

2

There’s no point in making scripts separately and then running them in the scheduler.

Non ha senso fare gli script a parte e poi richiamarli nello scheduler…

3

So you say that if you make a script that needs to be scheduled, just copy/past script in the scheduler and do not use the script function at all?

4

Indeed…

You don’t have a drop-down menu where you can choose the script, but an area identical to that of the scripts where you can insert… the script…

In the scheduler if you “call” the script, you just create a script that calls the script…

If you need to call the source of a script to do something else, you can do exactly the same with the scheduler text.

Difference between scheduler and script: none except that the script doesn’t start by itself, the scheduler can put a “timer” on it…

5

Learning new things every day. Thanks :slight_smile:

6

:+1:

7

Yes largely a difference without distinction.

Only two minor differences:

  • If you need the same script in multiple scheduled tasks… In this case, it be better to have your script in /system/scripts, so there be only one copy of your code to edit or change.
  • Or you want “manually” run your script… e.g. /system/script has “run script” while schedule does not (without changing the schedule).
  • In Schedule, you can just put the name of the script as the “On Event” to invoke another script, while in /system/script you have to use the full command to call another script.
8

thanks for the info, and since you can’t put reactions to every post I’ll put them here :+1::+1::+1::+1::+1::+1::+1: :laughing:

9

Better to have each script copied multiple times for each scheduler.
If for some reason you modify the script that is called by multiple schedules
and for some reason later turns out to be faulty, not just one, but all of the schedules stop working.
Or modifying the script could cause one or more schedules to no longer behave correctly if the script is modified,
for some unforeseeable reason at the outset.



not true:

[[:parse [/system scheduler get <SCHEDULER_NAME> on-event]]]
10

To the OP, as you can see it doesn’t matter. This is really just personal preferences.

FWIW something I do neither. Instead of script or schedule, I sometimes just copy a script with functions to the file system, and then use :import it (from CLI, schedule, etc.) to load the all my script functions. This is pretty quick to load a very large script file, and has a verbose=yes and start-after= options so you can debug a large script or ROS functions. So the file system be the third way, all have some differences (as you see here)

I have no idea why there is a strong opinion that ONLY valid way is ALWAYS put code in the schedule itself & never use schedule to call scripts – everything has it’s place.

not true:

[[:parse [/system scheduler get <SCHEDULER_NAME> on-event]]]

Yes I know how parse works. I was referring to winbox dialog box for “System Scripts” that has a nice little “Run Script” BUTTON… but schedule does not. At the CLI, you could call :parse with [[]] and remember it’s actually “on-event” not “script”… But “saved code” in /system/scripts, can be called using “run” (e.g. /system/script/run ) and likely more convenient (and potentially faster than :parse).

11

For me it’s just a matter of simplicity…

If I just want to “ping” what do I care about installing the user-manager that I don’t use anyway?

So a trivial script better not have many frills behind it, but do only what is needed, without carrying function libraries just to use a small function inside.

Also seen how things change without warning from morning to night, (for example /system health or RouterOS v6 / v7 differencies)
it takes little to find the whole library in error, instead of just that specific script.

In fact, a lot of users “trivially” want a script that does only one thing, then someone suggests that they install a whole library, just to use two lines of code in that library…
So that user is not only in trouble because he doesn’t know how to make scripts, but he also finds himself having to manage the “installation” of the libraries and all the frills that follow just for a microscopic function inside the library. ..

All tastes are tastes.