![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Debugging Features
This chapter contains the following debugging topics:
- Parsing
- Tracing
- Apex Shell Debugger
- Debugger Quick Start
- Debugging Standard cshell
- Apex Optimization
- Debugging Server Scripts
Parsingapex_shell supports the csh "parse only" option -n. However, unlike csh, apex_shell always completely parses the script first. If an error is found, execution terminates with an error messages that identifies the line number of the offending statement.
Due to late binding, parsing will not catch all errors. Consider the following statement:
$v.$op
This might translate into a legal procedure call, (such as v.show, where v is a view object), or it might translate into gibberish. Static parsing is not capable of catching this type of problem.
TracingApex shell supports the standard csh -x and -v tracing options. It also supports some more powerful options which provide additional detail.
Statement tracing indents statements to reflect the program structure. End statements are shown for clarity.
Apex Shell DebuggerThe apex_shell debugger is entered when a breakpoint is hit. The debugger displays a prompt and you can type a command.
Anything typed at the prompt which is not a debugger command is taken as a one-line shell command and is run in the context at which the program is stopped. Essentially, you have full access to interactive operation.
Variables can be displayed or set using the usual cshell command:
echo $var (Show a single variable)
echo `foo.op` (Show the result of object's operation)
set (Show all variables)
set var="a b" (Set a variable)
To see the debugger-specific commands, enter "?" a the prompt.
apexsh: ?
Commands
Debugger Quick Startapex_shell -d causes the script to break at the first executable statement. apex_shell -e executes the script to the point of an error before breaking. When debugging lengthy scripts, sometimes it's easiest to insert a break_here statement in the script at the point where you want to start debugging.
We'll walk through a script by way of example, using the following commands:
- show
- echo
- 1
- break <line number>
- run
Note that 1 will single step to the next line.
Start up in the debugger and display the program.
mario% apex_shell -d foo.apexsh
-- BREAK line: 1 /vc/gsmith/1.1 -- echo "There were $#argv arguments"
apexshdb: show
- 1 echo "There were $#argv arguments" 2 for ( set i=1 ; "$i" <= "$#argv" ; @ i++ ) 2 set i=1 2 @ i++ 3 echo `$'$i = $argv[$i] 5 <program_end>
Now we will step through: apexshdb: 1
There were 2 arguments
-- BREAK line: 2 /vc/gsmith/1.1 -- for ( set i=1 ; "$i" <= "$#argv" ; @ i++ )
apexshdb: 1
-- BREAK line: 2 /vc/gsmith/1.1 -- set i=1
apexshdb: 1
-- BREAK line: 3 /vc/gsmith/1.1 -- echo `$'$i = $argv[$i]
apexshdb: echo $i
1
Set a breakpoint by specifying the line number then run to it.
apexshdb: break 2
apexshdb: run $1 = hello
-- BREAK line: 2 /vc/gsmith/1.1 -- @ i++
apexshdb: show
1 echo "There were $#argv arguments" - 2 for ( set i=1 ; "$i" <= "$#argv" ; @ i++ ) - 2 set i=1 - 2 @ i++ 3 echo `$'$i = $argv[$i] 5 <program_end>
apexshdb: exit
Debugging Standard cshellSince Apex Shell is nearly a superset of cshell, in general apex_shell works for most scripts written in cshell. In particular, the Apex Shell debugger is a compelling tool to develop standard cshell scripts since there isn't a similar tool available elsewhere.
However, there may be cases where Apex Shell and cshell do not have exactly the same behavior. This is the same situation that sometimes occurs when moving cshell scripts from one architecture to another. If this happens, there are usually several different ways of doing the same thing, one of which works in both Apex Shell and cshell. Typically, breaking up a single complex statement into simpler component statements does the trick.
Use the +A option when invoking standard cshell scripts to suppress Apex Shell extensions.
Apex OptimizationStatements in an Apex Shell script which run certain Apex commands will execute the command directly, without forking a separate process.
apex_display
apexd
testmgmt
apex_guigen
apex_action
Apex_Build_SupportThis can have some performance benefit for a long running shell script with many invocations.
Debugging Server ScriptsTo change options in a running server which processes Apex Shell or dlisp scripts, there are special subcommands of apex_display.
apxd script_trace <editor_name
> [<value
>]
apxd script_trace directory
With no value given, it enables statement level tracing.
For example:
apxd script_trace dialog hilite_stmts apxd script_trace dialog lines
These can be suffixed with 0 to disable that characteristic, For example:
apxd script_trace dialog visit_stmts:0
If the server which is running a script that you are debugging is also the server which is used to visit files, the visiting and highlighting capabilities will not be available.
Set a Script Breakpoint
To set a script breakpoint in a server which processes these scripts you can use:
apxd script_break <editor_name
> <value
> [<value
>]
apxd script_break dialog fileOpen.init
- filename line_number
/sierra/products/apex.2.0.8.dev/dialogs/file_dialogs.dlisp 73
- a dialog prog name given as dialog_type.prog_name
fileCopy.exec
- a global function name from a %function in dlisp or a function clause in action files
- an action name from an action clause. For modified actions the form is modifier-action_name, for example, SHIFT-toolsFoo, SHIFT-control-actionName
- for an action written in Apex Shell, one of the words
start break on the first statement of any Apex Shell action executed
error break when an error occurs while running any Apex Shell action
end break on the last statement or on any error
Temporary script breaks can be set with:
apxd script_break <editor_name
> -temporary <value
> [<value
>]
apxd script_break dialog -temporary fileNewView.initTo enable the visit_source_on_break option:
apxd script_break <editor_name> -visit apxd script_break <editor_name> +visit (to disable).To remove all script breakpoints from within a server:
apxd script_break <editor_name
> -clearWhen a server encounters a script breakpoint and its standard input and output are not set to an xterm, it automatically creates an xterm window and redirects the input and output to that xterm.
If a server has been explicitly started in an xterm then this will not be necessary and the script debugging will be done there.
Script Tracing and Breaking Options
For a command executable which might invoke the Apex and Summit interpreter as part of its execution and run an Apex Shell script, for example, the taskmgmt executable running a customization action, there are command line options to control script tracing and breaking which can be given on that executable's command line:
-script_trace_value (-stv) <value>
taskmgmt -st -sb pre_foo subcommand arguments ... apxd -stv all check_rules -no_path foo.actions action_name
The values to give to these options are as described above for the apxd script_... commands. A two token value must be given as a single quoted string.
Reread the .dlisp file
Changes made to server scripts must be reread to be recognized by the server. For example, the debugger is run by the compiled version of a server script and changes to the script cannot be seen by the debugger until the script is reread.
For the dialog server, the command to reread a .dlisp file is:
apxd -editor dialog perform load <filename
>
To parse the file and check for errors, highlighting the errors in the editor:
apxd -editor dialog perform parse <filename
> or apxd -editor dialog perform parse -w <filename
>
For editor action files, the server can reread all of its rules files from the menus path. This command is:
apxd -editor <editor_name
> reread_rules
To parse an editor rules file:
apxd check_rules -w -no_path <filename
>
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2001, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |