...

These modifiers have to be put at the end of the line, and control if <Enter> will be sent after the command line.
The default behavior is to send <Enter> after each command line, UNLESS "$[no-enter]" is specified, or the command is a control sequence.
(please check the Command parsing examples section for more details)

Normally, Unimus waits for some know output (for example a prompt) after each sent command line (see How commands are sent to devices for more info).
There are 2 modifiers that can influence this behavior.

$[wait]
$[no-wait]

Specifying "$[no-wait]" will cause Unimus to instantly continue sending the next command line without waiting for any device outputs.
This can be useful when for example the device doesn't respond with any data after sending some command/line, and you want Unimus to continue sending data to the device.
(please check the Command parsing examples section for more details)

Unimus supports sending various control sequences to the device, in this format:

...

Sometimes, you want Unimus to send commands to the device even if the device doesn't output any known outputs after sending a command line.
For example, many devices don't respond with anything if you need to provide a text block. You can avoid "INTERACTION_ERROR" in this case like this:

banner motd ^
This is the start of the banner$[no-wait]
And this is a 2nd line of the banner$[no-wait]
This is the end of the banner

The interaction with the device will look like this:

Debugging failed pushes - "INTERACTION_ERROR" group

...