Function keys can be defined, only once per debugging session, by reading their definitions from a file. The name of the file can be passed on the command line with -k filename. The file may be as simple as this
[]kdefs.exm
Note that an uppercase F, which starts key definition, has to
be in the first column and it has to be immediately followed
by a valid key number. Shifed functions keys have numbers
between 11 and 20. A definition of 〈F2〉 is continued on the
next line since a terminating newline is escaped with a \
character. Otherwise this continuation line would be simply
ignored. szadb also does not pay any attention to the second
definition of 〈F1〉. To see a list of all function keys defined
type $k
.
Defined function keys can be used in two ways. Just hitting
a function key will insert into the current input line as many
characters from a corresponding string as it will fit.
The resulting input text can be edited.
In order to execute a full definition use $k
followed by a key
number — always in decimal.
For example, a request $k2
will print twice
the message, which was just defined in the function key file.
Note that there no way to specify that a function key should execute
immediately instead of waiting for a 〈return〉. Also is there no default
function key file name
like — adb.key — so you'll have to specify the
-k file
option on the command line each time or use a command alias.
Note also that requests of a form $k
<number> do not
autorepeat.
It is clear that strings of commands attached to function keys can be longer than a lenght of the input line. Actually around 2K will be accepted. This is hopefuly longer than any szadb script you ever want to write. Especially if you take into account that one script can call another. Warnings against recursion apply as well.
Such long scripts can be, of course, attached to breakpoints or stepping commands. They give also, previously mentioned, opportunity to fill all available space on a base page with command line arguments. Just define one of function keys as
:c <text to put on a base page>and execute at the beggining of your session. Coupled with a possibility of directly modifying the memory this allows for a preparation of scripts which will emulate any extended arguments scheme, even if szadb directly does not support directly any of these.