Global variables

A global variable is a value you set once and every button can use, with nothing declared on the button itself. Set KBSTECHLOG to your log collector's URL and any button, in any set, can send wget {{KBSTECHLOG}}.

It is the same {{NAME}} syntax the popup forms already used. The difference is where the answer comes from: a form asks you every time, a global is already there.

Setting one

Open Global variables from the {x} icon in the side panel header, or from the command palette. Add a row, give it a name and a value, save.

Names follow one rule, and the app enforces it: letters, digits and underscores, not starting with a digit. TFTP_HOST and _site are fine; 2FA and MY-VAR are not, and the form will tell you so rather than saving something no button could reference.

Where a global works

Everywhere a script takes text:

• the text a send block types;
• the arguments box on a runScript block, and its path and interpreter;
• the message and button labels on a confirm, and a pause message;
• the default value of a form field — including the popup form on the button itself;
• the values a button hands to another button it calls. A called set inherits the caller's globals.

One deliberate exception: expect and if match their pattern as a regular expression, and nothing is substituted into it. A {{NAME}} in a pattern is looking for those literal characters in the device's output, which is almost never what someone meant.

What wins

A value the button asks for at run time beats a global of the same name, and so does a field's own default. If a button has a form field called SITE and you also have a global SITE, what you type in the form is what gets sent. Globals are the background, not an override.

It is a text file, and it is yours

The form in the app edits a plain file. You can edit it yourself instead, keep it in git, or paste one in from a colleague — all of which is the point.

The app creates it the first time you save something. The file is read again on every button press, so editing it in your own editor while the app is open takes effect on the next press — no restart, no re-save.

The syntax

# Full-line comments start with #
KBSTECHLOG=https://logs.example.com/collect
export TOKEN = abc123           # "export" is accepted; spaces around = are trimmed
URL=https://host/path?a=1#frag  # the whole rest of the line is the value
PADDED="  keeps its spaces  "
BANNER="two\nlines"             # \n \r \t \" \\ are unescaped in double quotes
LITERAL='taken literally'

Two things follow from "everything after the first = is the value", and both are deliberate:

• There is no inline-comment rule, so a # inside a URL is safe. This is not dotenv. URLs with fragments are far more common in this file than trailing comments.
• A line the app cannot use — a bad name, no = at all — is reported to you with its line number rather than quietly dropped. Same for a name set twice: the last one wins, and the app says so.

Comments survive editing through the form, so a note explaining why a URL is what it is stays put when someone changes the value.

Sharing a set that uses one

This is what makes globals worth the trouble on the exchange. Your value never goes into the exported file — only the name does — so you can share a set that talks to your syslog server or your TFTP host without publishing the address.

The flip side is that a downloaded set can quietly do the wrong thing. On 1.0.0 or 1.1.0, or on 1.2.0 where the name is not set, the placeholder is typed at the device exactly as written — wget {{KBSTECHLOG}}. So every listing says up front which globals a set expects, and asks the uploader to describe what each one should contain. Read that before you press the button, not after.

Next: sharing a set.