There is a special startup value for “Start Time” you can enter which makes it runs once 3 seconds after reboot.
If by then your router isn’t fully “up” yet (i.e. waiting for PPPoE or DHCP network settings), then inside the script you can perform a delayglobal command as shown in the code fragment from the below forum post.
Don’t you love how people still tend to both repeat themselves and abbreviate stuff even though they have code completion at their disposal?:
{:delay 10};
/log print file=([/system identity get name] . "Log-" . [:pick [/system clock get date] 7 11] . [:pick [/system clock get date] 0 3] . [:pick [/system clock get date] 4 6]); \
/tool e-mail send to="xxx@xxx.com" subject=([/system identity get name] . " Log " . \
[/system clock get date]) file=([/system identity get name] . "Log-" . [:pick [/system clock get date] 7 11] . \
[:pick [/system clock get date] 0 3] . [:pick [/system clock get date] 4 6] . ".txt"); :delay 10; \
/file rem [/file find name=([/system identity get name] . "Log-" . [:pick [/system clock get date] 7 11] . \
[:pick [/system clock get date] 0 3] . [:pick [/system clock get date] 4 6] . ".txt")]; \
:log info ("System Log emailed at " . [/sys cl get time] . " " . [/sys cl get date])
#creates a new file descriptor 3 that redirects to 1 (STDOUT)
exec 3>&1
# Run curl in a separate command, capturing output of -w "%{http_code}" into HTTP_STATUS
# and sending the content to this command's STDOUT with -o >(cat >&3)
HTTP_STATUS=$(curl -w "%{http_code}" -o >(cat >&3) 'http://example.com')
use these policies as a minimum for scripts and schedules:
read
write
policy
test
Forum post:
I found out two things:
the testFunctionScript needs at least these policies to call a function: read, write, policy, test
a schedule needs at least the same permissions as a script in order to run the script at all
This is how the various permissions affect the testFunctionScript script:
no policies only allow :log info "testFunctionScript"; .
read allows the above and :local testFunctionJobs [/system script job print as-value detail]; which then is be logged with :log info "testFunctionJobs=$testFunctionJobs";
only write seems equivalent to no policies as it will only allow :log info "testFunctionScript";
read and write is equivalent to read
a lone policy or test policy (talk about confusion!) do not add functionality, so any combinations of just policy or testwith read and/or write get the same functionality as above
policy and test without any other seem equivalent to no policies as they result in only :log info "testFunctionScript"; to execute
the combined policies read, write, policy, test allow full script functionality including the function call and using the function call result
The above findings show that more logging is needed: the scheduler should log when (and why!) it does not have enough permissions to run a script. Right now you’re in the dark on when (and why!) a script isn’t ran by the scheduler.
The above findings show that these parts of the documentation need updating:
Yes there is; it’s the answer below. Note I needed to exclude false by adding a check value === false to the code below as that was a valid value for me.
You can just check if the variable has a truthy value or not. That means
if( value ){}
will evaluate to true if value is not:
null
undefined
NaN
empty string (“”)
0
false
The above list represents all possible falsy values in ECMA-/Javascript. Find it in the specification at the ToBoolean section.
Furthermore, if you do not know whether a variable exists (that means, if it was declared) you should check with the typeof operator. For instance
if(typeof foo !=='undefined'){// foo could get resolved and it's defined}
If you can be sure that a variable is declared at least, you should directly check if it has a truthyvalue like shown above.
Sort of tanslated from the first “via” (note that “mit Alles und Scharf” is hard to translate; it’s somewhere between “everything but the kitchen sink, but done right” and “right on the money”):
Bash Prompt Overkill: https://github.com/nojhan/liquidprompt is a Bash “Prompt doing it all right”-extension, which doesn’t care how much any feature costs as we have cores, gigabytes and SSD.
Liquid Prompt automagically recognises context and enables a plethora of features in the prompt when needed based on that context.
It’s like pixie dust for your prompt.
You can configure everything, but you don’t have to: the out of the box experience is already like pixie dust for your prompt.
It works on OS X too and is part of homebrew:
$ brew install liquidprompt
==> Using the sandbox
==> Downloading https://github.com/nojhan/liquidprompt/archive/v_1.11.tar.gz
==> Downloading from https://codeload.github.com/nojhan/liquidprompt/tar.gz/v_1.11
######################################################################## 100.0%
==> Caveats
Add the following lines to your bash or zsh config (e.g. ~/.bash_profile):
if [ -f /usr/local/share/liquidprompt ]; then
. /usr/local/share/liquidprompt
fi
If you'd like to reconfigure options, you may do so in ~/.liquidpromptrc.
A sample file you may copy and modify has been installed to
/usr/local/share/liquidpromptrc-dist
Don't modify the PROMPT_COMMAND variable elsewhere in your shell config;
that will break things.
==> Summary
🍺 /usr/local/Cellar/liquidprompt/1.11: 7 files, 125.6K, built in 3 seconds
[jeroenp:~/Versioned] 10s $
At the start [WayBack] it was more limited (from memory something like C#, TypeScript, Java Script languages and frameworks Node.js and ASP.NET 5) than my other development environments but now it’s much richer.
It’s based on the Electron framework which I kew from the Atom.io editor and Koush‘s framework Electron Chrome that wraps Chrome Apps in Electron so he ensured Vysor would live after Google will kill Chrome Apps.
Oh it’s free and runs multi-platform which I like a lot (and was one of the reasons to start using Atom.io): Mac OS X, Windows and Linux are supported.
I got reminded a while back** that it is now supported by OmniPascal [WayBack] which I like because of my Turbo Pascal -> VAX/VMS -> csh -> Delphi -> AS/400 -> .NET background.
Like Visual Studio Code is updated often, the Omni Pascal blog [WayBack] shows regular updates and I like it a lot better than the Lazarus IDE (I’m not a visual RAD person: I’m a RAD code person) especially the refactorings.
So start playing with it. I will post more about my Visual Studio Code experience in due time.
When logging on a Mikrotik is high-volume, then you need to have either:
separate logging actions (they end up in logging buffers each having the same name as the action) and logging rules for specific information that you want to retain
log to file in stead of memory
Since my devices have plenty memory, I made a separate accountAction with a rule sending the topic account to accountAction which I then can query like either of these:
/log print detail where message~"logged"
/log print detail where message~"logged" && buffer=accountAction
Here is the /system logging export condensed result:
As seen on TV! What if you could increase the resolution of your photos using technology from CSI laboratories? Thanks to deep learning and #NeuralEnhance, it’s now possible to train a neural network to zoom in to your images at 2x or even 4x. You’ll get even better results by increasing the number of neurons or training with a dataset similar to your low resolution image. The catch? The neural network is hallucinating details based on its training from example images. It’s not reconstructing your photo exactly as it would have been if it was HD. That’s only possible in Hollywood — but using deep learning as “Creative AI” works and its just as cool! Here’s how you can get started..
The Wiert Corner - irregular stream of stuff 