Glish provides some rudimentary tools to aid in debugging Glish scripts. These include reporting which events are generated (see the -v flag in § 11.1, page , and the discussion of the ``event monitor" in § 11.2.2, page , below), use of the print statement to provide debugging output, and use of the client function's suspend=T option, discussed in the following section.
Debugging Glish clients is primarily done using a conventional debugger and the suspend=T option to the client function (see § 7.8.1, page ). With this option, when the client is executed and constructs its Client object (see § 13.2, page ), the Client constructor will first announce itself, producing a message like:
tester @ myhost, pid 18915: suspending ...and then suspend itself by entering the following loop:
suspend = 1; while ( suspend ) sleep( 1 );A debugger such as gdb or dbx can then be used to attach to this running process. Once attached, set the variable suspend to 0 (or glish_false), set any breakpoints needed for debugging, and continue the process.
In addition to the suspend=T argument to client, every time Glish creates a new client the interpreter inspects the environment variable $suspend to see whether that client's name occurs in $suspend's (blank-separated) list of names. For example,
glish suspend="my_demo ./bin/camac" my_script.gwill execute the script my_script.g and whenever a client with the name my_demo or ./bin/camac is executed, the client will act as though suspend=T had been specified.
Note that the name here refers to the actual name of the executable and not the name of the variable to which the result of the client() call is assigned. For example, the above suspend list will not suspend a client created by the following:
my_demo := client("./my_demo")
If when the Glish interpreter starts running the $glish_monitor environment variable is set, then the interpreter takes the value of the monitor as designating the name of a client to serve as an ``event monitor".
The event monitor is sent an event every time either the interpreter receives an event from a client, or sends an event to a client or a subsequence. The former results in the monitor receiving an event_in event, the latter in an event_out event (i.e., ``in" and ``out" are relative to the interpreter's perspective). The event's value is a record with three fields: id, which identifies the agent associated with the event; name, the name of the event; and value, the value of the event.