Scripts Run Through the Applications CLI

One last hook in MicroMonitor is worth mentioning. Suppose you are now at the applications CLI (not the monitors CLI), and you have a script in TFS that you want to execute. You give the script some name that does not conflict with any other command name , say widget_script . You type widget_script at the applications CLI, and, through the mechanism discussed above, the command passes through to the monitor. The monitors CLI passes it to TFS for execution as a script.

This design works fine, as long as the script contains only monitor commands. You cannot, however, use this approach to get free scripting for your applications, because, by default, the script runner uses docommand() (in monitor space) to process each line of the script. Application-specific commands in the script are not recognized.

However, the script runner already has provisions to address this situation. The script runner always uses a function pointer to access a CLI function. By default, this function pointer is loaded with the monitors docommand() function, but this pointer can be overridden to reference a function in application space.

 #include "tfs.h" #include "monlib.h" mon_tfsctrl(TFS_DOCOMMAND,(long)appDocommand,0); 

The preceding code tells the monitors script runner to use the function appDocommand() instead of the default docommand() . ( tfsDocommand() is the function pointer used by the script runner.) With this single modification, the application can get free scripting. At the applications CLI, you issue the command widget_script . This command falls through to the monitor, and the script runner executes each command through the appDocommand() function that was assigned to the tfsDocommand function pointer. The applications CLI processes commands for both the application and monitor. Hence, the script runner in the monitor can be configured to execute commands from both the applications CLI and the monitors CLI.