First, a note on comments. The safest way to create a comment is to begin a line with the exclamation point character. Lines beginning in this manner are ignored. However, since (as will be described below) history file lines all begin with a record identifiers, lines need not use have this comment delimiter. Any line not begun with a recognized record identifier is ignored. (I've used this duality to good effect in the file $SPOCK/bin/webspock. This file is both a Bourne-shell script and a spock command file. Check out the file to see how that was done.)
As mentioned, valid spock history lines begin with a record ID. This is simply a string of three or four uppercase characters, followed by ``>'' and one or two spaces so that the total length of the record id is six characters. The record ID simply indicates what kind of information is contained in this line. The various record types are described below:
Recall that there's a difference between QUIT and quit in TEXT> records. TEXT> quit is ignored in history, while TEXT> QUIT is not, and will terminate spock.
If the final MENU> entry in a given cascade is a check box, (as in the Display menu) or a radio button (as in the picking) menu, the name of the is followed by a {1} or a {0} to indicate if the button is being turned on or off. Note that the spelling and capitalization of menu lines must match exactly their true values, or spock will not be able to read the file. A sample menu cascade is listed below. This is the sequence to set the atom rendering mode to solid spheres via the Alter Atoms menu:
TEXT> menu
MENU> Alter
MENU> Atoms
MENU> Solid spheres{1}
Define atom subset menu. These records are
distinct from the TEXT> records to 1) make them easier to
find and edit and 2) to allow for missing LINE> records for
macro mode (see §6.10). LINE> records must
immediately follow the commands that caused it to appear. If
cancel is selected on the prompt a LINE> cancel record is
written. Yes/No dialogs are treated like prompts, and a
LINE> yes or LINE> no record is written. Note that in
history files, the prompt title is written as a comment. This is
simply for clarity and is not required for correct processing.
In normal history mode, when there's a command that expects a file name (e.g. a MENU> Open, MENU> PDB file sequence) there may be any number of lines of other commands before the FILE> record appears. This is normal, as some of the save commands have special menus that are only present after the save command is given. The situation is slightly more complicated in macro mode. There may still be any number of lines before the FILE> line; however, if the end of the macro is reached before the FILE> line, one of two things can happen. First, if the macro was called from a history file, the next line (and only the next line) of the calling history file is checked to see if it's a FILE> line. If it is, that file is used. If not, an interactive request is generated. The macro programmer can force a macro to check the history file or go interactive at any point in the macro, by placing a FILE> line in the macro with nothing else on the line. The file $SPOCK/examples/filereq.sp has an example of this usage.
When a FILE> record is encountered while reading from a history or command file, you are not asked to verify writes, even if the specified file exists. This is to facilitate batch-mode processing that doesn't need to be attended. Of course, if you're not reading from a history file (i.e. in an interactive session), you're still asked if it's OK to overwrite existing files.
Attach motion menu.
Attach motion menu.