TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Using Apex Shell

The Apex Shell scripting language is implemented by the interpreter apex_shell. This discussion of Apex Shell (the scripting language) and apex_shell (its interpreter) parallels that of cshell (the language) and csh (its interpreter).


Command-Line Options

The interpreter apex_shell takes some of the standard csh options and supplements these with some of its own. To display the available options, type apex_shell with no arguments.

Usage

Options

-f
don't read ~/.Rational/apexshrc
-c
process command argument
-r
process rest of line as a command
-v
trace statements
-x
trace substituted statements
-V
-v when rc file read
-X
-x when rc file read
-n
parse only don't execute
-N
parse multiple csh files from args
-i
read commands from terminal
-I
read commands from stdin
+A
allow no apex extensions
-P
perform preprocessing
-l
show line numbers in trace
-a
show subexpressions in trace
-d
break at first statement
-e
break on error
-k
break on interrupt
-z
break at program end
-s
visit source on break
-w
highlight source on error
-W
visit source on error
-h
highlight each statement executed
-H
visit each statement executed
-j
highlight statements at end
-b
lnum break at line number
-b
func break at first statement of func
-b
file:lnum break at file line_number
-bt
arg set temporary break


Interactive Operation

apex_shell -i runs the interpreter interactively. This can be very useful to develop small scripts or portions of scripts, or to explore the behavior of unfamiliar objects.

Use exit to terminate the shell:


Running Apex Shell Scripts

As with csh, provide the filename of the script as an argument following any apex_shell options. Any arguments following the script's filename are passed to it as arguments.

Batch Scripts

Often you want to be able to execute a script written in Apex Shell without explicitly invoking apex_shell. The usual UNIX convention is to set the file's execute permissions and start the first line with #! followed by the interpreter's pathname.

However, the pathname must be fully-qualified and cannot contain environment variables, while the apex_shell executable (which is actually an entry point into apex itself) is not loaded into a fixed location.

One method is to simply put the full pathname to apex_shell in the file:

This works only for a single-architecture site, since it points directly to the executable for Solaris. A site that also had Apex for, say, HP-UX would want the script to use the executable that matches the current machine.

A more flexible strategy is to create a link such as /bin/apex_shell on each machine, linking this name to the architecturally correct apex_shell. Then the top of the script would simply be #! /bin/apex_shell.

While this provides portability, it does require maintenance on each development machine. Also, /bin/apex_shell will need to be updated if a newer version of Apex is installed in the future. Finally, large installations may end up running several versions of Apex concurrently, obviating this approach.

A third strategy is to use a wrapper to call the interpreter apex_shell. In this example, to call the script do_it.apexsh, we create the following Bourne shell wrapper do_it in the same directory and set its execute permission.

While this approach avoids the drawbacks of the other two, it comes at the expense of an extra file for each script.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS