TeSSH

Events are quite similar to aliases. At the simplest level, events need a name and a script, just like aliases. Unlike aliases, events aren't triggered by typing their name on the command line or as a command in a script.

Events are raised with the #RAISEEVENT command. TeSSH also includes some Predefined Events that it will raise when certain things occur.

Events can be viewed by clicking the Settings button on the main toolbar and then clicking the Show Events filter button on the far left of the Package Editor. To edit an event, just click its name and the details will be displayed in the right half of the window. To create a new event, click the New button at the top of the Editor and choose New Event.

The Editing Events topic has more info on using the Package editor to edit events.

The #EVENT command

You can also use the #EVENT to define an event from the TeSSH command line.

#EVENT name {commands}

defines a new event. Events can have arguments just like aliases can, and they're accessed in exactly the same way:

#EVENT OnError {#IF (%1 = 401) {do stuff}}

Events can also have named arguments:

#EVENT OnError($code) {#IF ($code = 401) {do stuff}}

%params and %-1-%-99 can also be used just like they can be in aliases.

The #RAISE command

You can use custom events to improve the working of your scripts. Events raised with the #RAISE command can be given parameters:

#RAISE OnError 401

raises the event defined above and sets $code to the value of 401. You can also use the #RAISE command to raise any of the predefined events in TeSSH, though you should obviously be careful when doing so.

Some ideas for using events

Events are useful in a number of situations.

• For sequences of commands that you want to use many times in your scripts but don't want to type out every time. This provides an "alias" that cannot actually be accidentally executed from the command line.
• For communicating across packages. While aliases should have unique names, events aren't so limited. Instead of having many onError triggers in different packages that all do different things, you could have a single onError trigger that raises an onError event and many events in different packages that're named onError. This is not only much faster than having many triggers, but is also much easier to edit if you change your prompt or something.