This chapter contains both the guide and reference information necessary to customize the graphical user interface.
Customizing the graphical interface involves editing group files. A group file (.grp) defines a set of named operations — a menu. A group file's scope declaration determines exactly where the menu appears in the interface — file browser toolbar, pulldown menu, vtree browser popup menu, and so on.
Each group file entry, or item definition, defines a single menu item. These menu items typically have names like checkout or merge, but there are no inherent restrictions; labels and operations can be entirely unrelated to ClearCase. You can customize any menu item to perform any operation expressible as a shell script.
The “meat” of an item definition is a function call, command line, or shell script (several of these can be combined in one item definition). An item definition can also specify multi-state icon bitmaps, a menu mnemonic, whether to execute in the background, and so on.
The default, predefined group files are installed in /usr/atria/config/ui/grp. You should not edit these files in place. It is also not advised to copy and edit them elsewhere — they amount to “source code”; future ClearCase enhancements and bug fixes will leave you behind.
To add your own menus, create new group files in the .grp subdirectory of your home directory ($home/.grp:/usr/atria/config/ui/grp is the the default group file search path). Alternatively, specify a group file search path with the environment variable grp_path, and do your customization work in any of its component directories. Copy to your work area the predefined group file template /usr/atria/config/ui/grp/user.grp.template, and use it as a template for your own work. (This template is scoped to the Fast menu, so you can use your additions as pulldown menus or add them to the toolbar as “push buttons”. See “Scope” for details.)
Upcoming sections describe group file contents in detail. Look ahead to “Customization Procedures” for more recommendations regarding the customization process.
![]() | Note: If you are responsible for implementing or maintaining the graphical interface for a group of people, make your group file customizations in one or more globally accessible directories and see that each user's grp_path environment variable gets set accordingly. Also, note that you can use grp_path to control which menus are visible to which users. |
The default search path for group files is $home/.grp:/usr/atria/config/ui/grp. You can override this search path with the environment variable grp_path. The grp_path can include any combination of directories and files.
When you start xclearcase, it traverses the group file search path, collects all group files, and caches them in ASCII-sorted order. (This determines the order in which pull-down menus appear on the menubar.) If a group file has syntax errors, messages appear in the transcript pad, and all or part of the group file is ignored. If xclearcase encounters more than one group file with the same leaf name, it uses the first one found (permitting you to “eclipse” a group file with one of your own).
Using the cached group files, xclearcase builds the menubar, toolbar, and popup menus for various browser classes.
First, let's look at a group file. Figure 18-1 shows a file browser and its menus, which are defined by group files. The Basic pulldown menu is defined by the group file basic.grp, which appears in Figure 18-2.
Although the basic.grp file and Basic menu are fictitious, they illustrate the structure and function of group files.
You may have noticed similarities between group file syntax and that of X window manager startup files like .mwmrc or .twmrc. As in a .mwmrc file, the ! and # characters can begin comment lines, and an unquoted, un-escaped # in any column comments the rest of the line. The backslash (\) escape character doubles as the line continuation character.
The file begins with a Scope definition. (Scope is described below.) Each group file defines exactly one primary menu and names it with a RootMenu declaration. The RootMenu declaration is followed immediately by a line containing only an open brace character ({). Submenus, if there are any, are named with Menu declarations.
Each menu item definition is a single logical text line that includes, in order:
a label
optional bitmap files (for toolbar items)
an optional menu mnemonic
an optional preselect clause
an optional ampersand (&), to run a menu item's command operation in the background
one or more f-dot functions — usually an execution string
a “popup” help text string
The menu declaration ends with a closed brace character (}).
You may also have observed that the execution scripts, or f.exec strings, in basic.grp contain unfamiliar uppercase keywords, prefixed with the % character. These are ClearCase macros, inserted to perform specialized tasks, like prompting the user for more data or redirecting output to a browser. An input macro, like %pname, can serve two functions: (1) to prompt for interactive input, and (2) as a preselect clause, which specifies the conditions necessary to activate the menu item.
Figure 18-3 restates these rules.
The following subsections describe first the Scope and RootMenu declarations that begin a group file, and then, the individual components of an item definition.
Scope browserClass [, browserClass ]... : menuType [ , menuType]... |
Each menu — pulldown, popup, or toolbar — corresponds to a .grp file. The menu definitions (.grp files) all have the same structure and syntax, but they have different scopes. A menu can have one of four basic scopes:
| Fast:pulldown |
| |
| browserClass:pulldown |
| |
| browserClass:popup |
| |
| browserClass:toolbar |
|
The browserClass is one of the following as shown in Figure 18-4:
The menuType is one of:
pulldown popup toolbar |
If a menu has no scope specifier, it defaults to *:pulldown and, therefore, appears as a pulldown menu on all browsers.
For example, the ClearCase-supplied group file file_popup.grp begins with the following line, which defines it as the popup menu for all file browsers:
Scope File:popup |
For any browser class, only one menu can be explicitly scoped to the toolbar or pop-up menu. (See “Fast Menu Scope” to learn how to create a pull-down menu that can be appended to the toolbar.) If you choose to replace a browser's toolbar or pop-up menu, follow the procedure described in “Replacing an Existing Menu”. If you depart from this procedure, and use a group file with a different name than the standard menu, make sure the new file name sorts ahead of the existing one; xclearcase ASCII-sorts group files when it first reads them in.
The Fast scope is compatible only with menu type pulldown; Fast:popup and Fast:toolbar scopes have no effect.
The Fast menu appears only on the file browser that comes up when you execute xclearcase. It does not appear at all if no menu is scoped to it. If you close the original file browser, the Fast menu is lost for the duration of the xclearcase session (even if you start a new file browser with the Filet -> New file browser option on another browser).
The Fast menu's distinguishing feature is the Static menu option that is prepended to each menu scoped there. You can set the Static menu option to duplicate a menu as a set of “fast access” buttons below the file browser's iconic toolbar. (You could scope your “fast access” menu to File:toolbar, but since only one group file can be scoped to a browser's toolbar, the standard iconic toolbar would be displaced.)
Typical usage — “Pick and choose” a set of commonly used menu items from elsewhere in the interface, and collect them together as a “fast access” menu scoped to Fast:pulldown. When constructing the “fast access” menu, use the f.alias function to clone menu items that reside elsewhere in the interface.
Figure 18-5, Figure 18-6, Figure 18-7, and Figure 18-8 illustrate the results of scoping group files, respectively, to File:pulldown, File:toolbar, File:popup, and Fast:pulldown.
Note that it is the file name, not the menu name, that determines where in the menubar the View menu appears.
RootMenu menuName [ _mnemonicChar ] |
For menus scoped pulldown, the RootMenu name is the character string that actually appears in the interface. The RootMenu name has no effect on menu location; that is determined by sorting the names of the group files themselves (See “How xclearcase Processes Group Files at Startup Time”.) See also “Menu Mnemonics” for details on specifying an optional menu mnemonic character.
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
"label string" or no-label
|
Item labels are quoted character strings (labels without blanks do not require quotes, but they are recommended for consistency). If the item is scoped to a toolbar, and its definition includes bitmaps, then the item label is not visible in the interface. In all other cases, this is a user-visible label for the menu item. Use no-label to suppress a label — with f.separator, in particular.
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
@unarmedFilename[,armedFilename[,insensitiveFilename]]
|
You can specify bitmap icons for RootMenu menu items scoped to a toolbar. Bitmaps for submenu items, or for items not scoped to a toolbar, are ignored.
The first two bitmaps represent the “unarmed” and “armed” (depressed) states. These two states correspond to “off” and “on” for two-state toggle buttons. (See the builtin function descriptions in section “f.call”.) The third bitmap is displayed when the item is insensitive, or “greyed out”. A toolbar button with a preselect clause needs all three bitmaps.
Bitmaps supplied in item definitions must be stored in /usr/atria/config/ui/bitmaps; otherwise, they must be full pathnames (including suffixes). Do not confuse toolbar bitmaps with file browser icons, which are managed as described in cc.icon (and in the section “Icon Display in the File Browser”).
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
_character
|
The underscore character is required; character is a single, printable character, which must occur in the label string. The first occurrence of character in the label string is underlined — but only if the character's letter case (upper or lower) matches the case in which it appears in the label string.
Menu mnemonics enable keyboard access to menus and menu items. See Table 3-2 in Chapter 3, “Using the ClearCase Graphical User Interface,” for a description of how menu mnemonics are used to navigate menus.
A mnemonic character has no meaning for an item or menu scoped to a toolbar.
label [ bitmaps ] [ mnemonic ] [preselectClause ] [ & ] function [ f.help "text" ]
% dataType[preselect-count](restrictions)
|
The preselect clause defines the conditions necessary to activate the menu item. The item is “greyed out” until the user selects at least one object that satisfies the preselect clause. If there is no preselect clause, the button or menu option is always enabled.
A preselect clause has three parts:
a single data type (or input macro) keyword; see “Input Macros” for a information on how to construct this piece of a preselect clause.
an optional “how many?” specifier, inside square brackets, which specifies the number of applicable data items the user must preselect in order to enable the menu item; some representative examples:
| none | user must preselect exactly one item | |
| [] | same as [1+]; user must preselect one or more items | |
| [2] | user must preselect two items | |
| [2+] | user must preselect two or more items | |
| [2-4] | user must preselect between two and four items, inclusive | |
| [0+] | no preselection requirement | |
| [0] | no preselection permitted (item not enabled if any data is selected) |
a parenthesized list of restrictions (see the restrictions arguments to the various input macros in the section “Input Macros”). The actual restrictions are optional; the parentheses are not.
Preselect clauses are closely linked to the %selection macro. If an item definition includes a preselect clause, its execution script includes at least one %selection macro, which is replaced by the preselected data at execution time.
You cannot have the user preselect multiple data types (three pathnames and two label types, for example). If your menu item operation requires multiple kinds of data, or it requires data items in a particular sequence, you can get only one type of data, or one argument, via preselection. You must use one or more additional mechanisms to collect the remaining input; xclearcase input macros and clearprompt exist for this purpose.
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
&
|
Include an ampersand character to have the menu operation execute in the background. When a script executes in foreground mode (no &, the default), the watch cursor blocks other commands until the currently executing f.exec script (or f.call) is complete.
For backgrounded item definitions, all f.exec scripts except the last one behave like foreground scripts. The last (or only) f.exec script runs in the background. Any f.call functions that follow the last f.exec run in the foreground, without waiting for the f.exec to complete.
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
|
Each item definition includes at least one of the following functions in Table 18-1.
Table 18-1. Group Item Functions
F-dot | Argument | Description |
|---|---|---|
f.alias | aliasedItem | Duplicate an existing menu item. |
f.call | builtinCall | Call a built-in function. |
f.exec | execString | Execute the command or shell script when the button is pressed or menu option selected. |
f.separator | none | Insert a dividing line in the group menu. |
f.menu | submenuName | Specify a submenu (“cascading” menu). |
f.help | helpString | Specify help text for item. |
Quoting — The argument to any f-dot function can be quoted with either %QUOTE% keywords or quote characters (""). %QUOTE % keywords permit unescaped quote characters (") to appear in the argument. See also “Group File Processing and Macro Expansion”.
f.alias "groupFileLeafName/menuSpecifier/itemLabel" |
Duplicates an existing menu item from another group file. An “aliased” item inherits the following characteristics from an existing menu item definition:
preselect clause
foreground/background execution specifier
all f-dot functions (f.calls, f.execs, f.menu, f.help, f.title, f.alias)
example as shown in Figure 18-9 (from file_popup.grp)
![]() | Note: The menu name root in the second example. Use root if the menu item is defined in the target group file's RootMenu. |
You cannot override f-dot functions in the alias definition. Also, an f.alias function cannot be combined with other f-dot functions.
f.call "builtinFunction" |
Calls one of the built-in xclearcase functions. Many of these calls toggle browser display parameters. (See /usr/atria/config/ui/grp/file_pulldown_G_options.grp, for example).
There are also calls to invoke or “pop up” each of the xclearcase browsers. Others perform miscellaneous operations, like closing a browser or quitting xclearcase.
If the builtinFunction call includes an argument with literal quotes, quote the call with %QUOTE% keywords, instead of quote characters (").
Some of the f.call functions create two-state toggle buttons (rather than “push buttons”) automatically. Figure 18-10 shows iconic and textual examples of two-state toggle buttons
These builtin calls exist to let you position toggle buttons using the menu scope of your choice. Note that you do not get default graphical icons if you scope a toggle item to a toolbar; supply them in the menu item definition like the ClearCase-supplied group files do.
A “customized toggle button” is any toggle button you create with an f.call whose description in Table 18-3 begins “Enable/disable”. Adhere to the following guidelines to guarantee that the state of a customized toggle button is always predictable:
In a single item definition, do not combine a toggle f.call with any other f.calls or f.execs. You may be tempted to try and control multiple parameters from a single menu item. However, because xclearcase frequently adjusts these parameters internally in response to other user operations, the state of a toggle button that controls multiple parameters may become inaccurate with respect to one or more parameters.
Do not create two toggle buttons for the same parameter on the same browser, as their states are likely to become confused.
Table 18-2 documents the built-in calls.
Call[a] | Description[b] | Applicable |
|---|---|---|
XXTYPE pname | Bring up type browser for VOB identified by pname. | all |
CLOSE | Close current browser. | all |
FILE directory-pname | Bring up file browser on directory-pname. | all |
FILE_DISP_DATE | Enable/disable size and date modified display. | file |
FILE_DISP_OWNER | Enable/disable owner and permissions display. | file |
FILE_DISP_RULE | Enable/disable config spec rule display. | file |
FILE_DISP_TYPE | Enable/disable object type information display. | file |
FILE_DISP_VERSION | Enable/disable version information display. | file |
FILE_SORT_BY_CHECKO UT | Enable (disable by-rule and by-type)/disable sort- by-checkout for file system objects in file browser. | file |
FILE_SORT_BY_RULE | Enable (disable by-checkout and by-type)/disable sort-by-rule for file system objects in file browser. | file |
FILE_SORT_BY_TIME | Enable/disable “minor”[c] sort-by-time. | file |
FILE_SORT_BY_TYPE | Enable (disable by-rule and by-checkout)/disable sort-by-type for file system objects in file browser. | file |
FORCE | Force update of current browser. | all |
GRAPHIC | Disable/enable graphic (icon) display mode. | file, vtree |
KEYBOARD | Enable/disable the keyboard input box for the current browser. | file, xxtype, pool, VOB-tag, view-tag |
LIST_DELETE_SELECTED | Delete selected items from the current list browser. | list |
POOL pname | Bring up pool browser on VOB identified by pname. | all |
print | Send PostScript image of vtree to output-pname. | vtree |
QUIT | Quit xclearcase. | all |
SETVIEW view-tag | Set the process's current working view to view-tag.
| all |
SHOWTRANS | Bring up the transcript pad. | all |
TYPE_DISP_ACTIVE | Enable/disable display of active objects. | xxtype |
TYPE_DISP_LOCKED | Enable/disable display of locked objects. | xxtype |
TYPE_DISP_OBSOLETE | Enable/disable display of locked-obsolete objects. | xxtype |
UPDATE | Update any browsers marked for update. By default, browsers are updated when a GUI command completes, or whenever 15 seconds elapse without any GUI activity. | all |
USERNAME | Bring up username browser. | all |
VIEWTAG | Bring up view-tag browser. | all |
VOBTAG | Bring up VOB-tag browser. | all |
VTREE element-pname | Bring up vtree browser on element-pname. | all |
VTREE_DISP_ALL_LABEL | Enable/disable all labels display (disabled: max=5). | vtree |
VTREE_DISP_ALL_VER | Enable/disable display of all versions (disabled: show “significant” versions only — branch points, labeled versions, and hyperlink endpoints). | vtree |
VTREE_DISP_CHECKOUT | Enable/disable display of checked-out versions. | vtree |
VTREE_DISP_MERGE | Enable/disable merge arrow display. | vtree |
[a] Arguments are required, unless enclosed in brackets ([]). [b] For two-state toggle functions, the first word in an “enable/disable” pair specifies the state that corresponds to “on” or “armed”. [c] A “minor” sort parameter applies only to data items within the subsets created by the “major” parameters. | ||
While xclearcase macros are most common in f.exec strings, they can appear in f.call arguments as well. Here is a common example:
f.call "VTREE %SELECTION()" |
See the sections “Group File Processing and Macro Expansion” and “xclearcase Macros” for details on xclearcase macros.
f.exec %QUOTE%execString%QUOTE% |
Executes a command line or command script. The argument to f.exec is an executable command or shell script, enclosed either by double-quotes (" ") or by %quote% keywords.
By default, /bin/sh is used. Include a first line like #!/bin/csh to specify another shell.
In a single item definition, you can combine an f.exec script with one or more additional f.calls and/or f.execs. However, if an f.exec script returns a non-zero exit status, f-dot processing terminates for the current operation.
If the execString includes an argument with literal quotes, quote the execString with %QUOTE% keywords, instead of double-quote characters ("). In general, it is highly recommended that you use %QUOTE% for complicated scripts.
Because xclearcase adds macro expansion to f.exec string processing, quoting and character escaping are different than in ordinary scripts. For details on macro expansion, and on using the specific macro themselves, see the sections “Group File Processing and Macro Expansion” and “xclearcase Macros”.
Environment Variables. If you set the environment variable clearcase_dbg_grp to a non-zero value, xclearcase sends debugging information to the transcript pad when executing commands.
If they are not already set, xclearcase sets the atriahome and grp_path environment variables to their default values when it starts up. (atriahome defaults to /usr/atria; grp_path defaults to $home/.grp:$atriahome/config/ui/grp.) This means you can rely on the existence of these variables when writing scripts.
no-label f.separator |
Inserts a separator line in a menu, or breaks the horizontal run of a toolbar button set. As for any item definition, a label is required; use the keyword no-label instead of a quoted label string.
f.menu submenuName |
Specifies a submenu to include in the current menu or submenu (no effect for a menu scoped to a toolbar). The submenuName specifies a menu that is named in a Menu declaration in the same group file.
Figure 18-11 shows a “cascading” menu — the ClearCase menu, and its submenu Checkouts. Figure 18-12 shows an abbreviated version of the group file that defines the ClearCase menu.
![]() | Note: The submenu name, referenced in the f.menu function and in the submenu definition, is not the label that appears in the interface. As with all item definitions, the quoted label string, Checkout Info in this case, is what the user actually sees. |
label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ] |
Specifies help text, which is displayed in a popup window when the user presses rightMouse over the menu item (if it is enabled). It is good practice to supply popup help text for all items that include f.call or f.exec functions. There is no need to supply help for f.menu declarations; users cannot access help text on non-command menu items.
When supplying help text, keep each line under approximately 70 characters, to prevent lines from wrapping in the default-sized “popup help” display window.
If the helpText includes literal quotes, quote the execString with %QUOTE% keywords, instead of quote characters (").
Command script quoting and special character escaping are somewhat different than in standard scripts due to the addition of xclearcase macros (see also “xclearcase Macros”). Three passes are made over your f.exec scripts, two by xclearcase and one by the unix shell:
When xclearcase starts up, it scans all group files to build the menu interface.
When the user selects a menu item, xclearcase expands macros in the item's execution script. (This discussion focuses on f.exec scripts, but applies as well to the less common f.call functions.)
Once xclearcase macros have been replaced with appropriate strings, the command, or command script, is passed to the unix shell, which performs its own substitutions and executes the commands.
If an item definition includes multiple f.exec scripts, each is evaluated and executed separately, first to last.
The template file /usr/atria/config/ui/grp/user.grp.template illustrates many of the quoting, character escaping, and line continuation rules described in this section.
When xclearcase starts up, it scans the group files, checks syntax, and configures the various menus.
The execution script syntax analysis is simplified if you use %quote% keywords, instead of quote characters ("), to enclose your f.exec scripts. Using %quote% eliminates the need to escape backslash characters (\\n, for example) and quote characters (\") in scripts. Inside %quote% delimiters, there is no escape character, and no need for one.
Recall that an item definition is a single logical line. Therefore, a newline (<nl>) must be escaped with the backslash “line continuation character”, unless it falls inside quotes (", ', or %QUOTE% ).
![]() | Note: Continue to use line continuation characters in execution scripts as required by the unix shell. |
The percent character (%) is the xclearcase macro escape character. It is used to prefix macros, and to escape literal characters that might confuse macro processing — % (percent character) and ) (close parenthesis), in particular. If you want a % character to appear as a literal anywhere in an item definition (label string, prompt argument to an input macro, etc.) you must escape it, like this: %%.
Macro expansion — string substitution — occurs when user selects the menu item. In the case of input macros, macro expansion includes prompting for user input.
During this pass, xclearcase is looking for:
the macro escape character, %, which prefixes all xclearcase macros
after any macro keyword, the parentheses ( ) that enclose macro arguments
within parentheses, the commas that separate macro arguments
If you desire that %, (, or ) characters survive this pass (to appear in a macro prompt string, for example), escape them with the % character, like this: %% %( %).
If a macro argument includes a comma, quote the argument. (All macro arguments are strings, though only a few require explicit quotes.)
Macros can appear anywhere within the quoted f.exec string, and they can be nested as well. Macros are evaluated left-to-right; nested macros are evaluated from innermost to outermost.
Once macro expansion is complete, the unix shell makes pass 3, performing its own standard substitutions and executing the script. By default, /bin/sh is used to execute your f.exec scripts. Include a first line like #!/bin/csh to specify another shell.
Figure 18-13 follows an item definition through all three passes, illustrating how the execution string and its xclearcase macros are processed.
We have made numerous references to xclearcase macros. This section describes them more precisely and includes a set of tables to use as a reference.
xclearcase macros provide a specialized but straightforward string-replacement mechanism. The overall syntax rules follow:
Nesting — Macros can be nested to 32 levels, which are evaluated from innermost to outermost.
Arguments — Character string arguments for prompts and titles need not be enclosed in quotes:
%PNAME(Source file?,NELEM,file,ENABLE) |
This example specifies as a prompt the character string “Source file?”. Titles of browsers can be arbitrary character strings; in particular, they can include < SPACE > characters.
Extra white space is allowed between the arguments of a macro, even
< NL > characters. Also see Figure 18-14:
Parentheses — Macro arguments must be enclosed in parentheses. If you omit one or more arguments, you must use commas to indicate the “null” argument(s):
%PNAME(Source file? ,NELEM,file,ENABLE)
(Four explicit arguments)
%PNAME(Source file? ,,,ENABLE)
(Four arguments, two of them “null”)
|
Even if a macro takes no arguments, you must include the parentheses:
%SELECTION() (Macro that takes no arguments) |
Square brackets — With input macros only, you can use square brackets to collect multiple data input items. See “Input Macros”.
Table 18-3 lists all the xclearcase macros. The following sections describe the xclearcase macros in detail.
Macro | Brief Description |
|---|---|
|
|
Input Macros |
|
%ATTYPE[]() %BRTYPE[]() %ELTYPE[]() %HLTYPE[]() %LBTYPE[]() %TRTYPE[]() | Prompt for one or more attribute types Prompt for one or more branch types Prompt for one or more element types Prompt for one or more hyperlink types Prompt for one or more label types Prompt for one or more trigger types |
%HYPERLINK[]() | Prompt for one or more hyperlink objects |
%LIST[]() | Prompt for one or more list browser entries |
%PNAME[]() | Prompt for one or more pathnames |
%POOL[]() | Prompt for one or more VOB storage pools |
%STRING[]() | Prompt for one or more character strings |
%USERNAME[]() | Prompt for one or more user IDs |
%VIEWTAG[]() | Prompt for one or more view-tags |
%VOBTAG[]() | Prompt for one or more VOB-tags |
|
|
Modifier Macros |
|
%ELEMENT() | Strip version IDs from pathnames |
%ELEMSUFFIX() | Add extended naming symbol ( @@) to pathnames
|
%MOUNT() | Convert VOB pathnames to VOB-tags (mount points) |
%RELATIVE() | Convert names to relative pathnames |
%SETVIEW() | Convert pathnames to view-extended pathnames |
%SORT() | Return sorted list of pathnames |
%VERMOD() | Convert pathnames to version IDs (branch/version) |
%WHICH() | Return filename's full pathname from search path |
%WILD() | Expand wildcard characters in a pathname argument |
|
|
Output Macros |
|
%LISTOUT() | Redirect output to a list browser |
%TEXTOUT() | Redirect output to a read-only text window |
|
|
Memory Macros |
|
%SAVE() | Save a string in a named register for later recall |
%REMOVE() | Remove named register storage |
%RESTORE() | Restore a saved string from a named register |
|
|
Miscellaneous Macros |
|
%SELECTION() | Insert pre-selected data in f.exec string |
%TMPFILE() | Create a file in /usr/tmp (or in $tmpdir) |
%DIR() | Return directory associated with current browser |
%NAME() | Return name associated with current browser |
Input macros collect input from the user after he or she selects the menu item. Unlike the f.calls (vtree, file, vobtag, and so on) that launch new browsers, an input macro displays a text string prompt, and it does not “return” until the user selects data and presses Ok or aborts the operation with Cancel. Although the user can “interrupt” and perform other operations, the prompting browser waits until its original prompt is satisfied.
An input macro's prompt can appear in multiple browsers. For example, if the user has two file browsers up, a %pname macro's prompt will appear in both, as either is capable of returning the required data. Unlike its f.call counterpart, an input macro does not start a new browser if an appropriate one is already displayed.
Input macros, in abbreviated form, double as the preselect clauses in item definitions. The macro tables that follow below document both uses; in particular, they include the various restriction parameters, which apply when composing both preselect clauses and f.exec scripts.
If your f.exec script calls a second script, which itself requires input from the user, use clearprompt in the second script. Note that some cleartool commands, when run from xclearcase, invoke clearprompt automatically to get user input. For example, a checkin command in an f.exec script uses clearprompt to collect a comment (if neither a comment nor -nc is supplied on the command line).
Most input macros have an optional keyboard argument, which you can use to enable keyboard input on the prompting browser. Always supply the ENABLE argument when the operation requires input strings that cannot, or may not, appear on the browser. For example, when defining a “make new directory” menu item, use ENABLE so the user can type in a new directory name.
In addition, you may want to use ENABLE even when the user could “point and click” from a browser; the keyboard input box lets users supply pathnames with wildcards, instead of having to select many individual items. In general, enable keyboard input whenever there is a chance the user will want to type in the required data items.
Each ClearCase data type has a corresponding input macro whose job it is to prompt for that type of data as shown in Table 18-4.
Table 18-4. Data Types, Browsers, and Input Macros
Input macro | Kind of data returned by macro |
|---|---|
%PNAME() | pathname |
%HYPERLINK() | hyperlink |
%LIST() | list data |
%POOL() | storage pool |
%ATTYPE(), %BRTYPE(), %ELTYPE(), %HLTYPE(), %LBTYPE(), %TRTYPE() | ClearCase type object |
%STRING() | character string |
%USERNAME() | UNIX username |
%VIEWTAG() | view-tag |
%VOBTAG() | VOB-tag |
The prompt from an input macro appears at the bottom of the browser display and includes Ok and Cancel buttons. After Ok or Cancel, auto-displayed browsers disappear. In general, browsers stay up when started with an f.call function; otherwise, they come and go as needed to satisfy the input macros in f.exec strings.
By default, an input macro seeks exactly one data item, and if the user selects more than one item, the operation fails with a Function not executed error message in the transcript pad.Use the optional square brackets on an input macro to collect multiple data input items. Note that the various numerical specifiers permitted inside brackets in preselect clauses do no apply to input macros.
If the user presses Ok, but the selected data does not satisfy the restrictions argument of an input macro, the transcript pad displays the script and the message Function not executed. (Note that the Ok button is not enabled until the user selects the number of data items that satisfies the [] construct.)
%ATTYPE[ preselect-count]( restrictions ) preselector %ATTYPE[]( prompt, restrictions, pname-in-VOB, keyboard ) macro (also: %BRTYPE, %ELTYPE, %HLTYPE, %LBTYPE, %TRTYPE) |
Prompt for one or more attribute, branch, element, hyperlink, label, or trigger types (see Table 18-5 and Example 18-1.)
Table 18-5. %ATTYPE Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Select xxx type(s) |
restrictions | ACTIVE or LOCK or OBSOLETE | any type object |
pname-in-vob | Pathname in any VOB | VOB containing working dir |
keyboard | ENABLE | not enabled |
f.exec %QUOTE% cleartool mkbranch %BRTYPE(Which branch?,,,ENABLE) %SELECTION() %QUOTE% |
Each xxtype macro invokes a corresponding type browser on a particular VOB. Use the restrictions argument to limit the kind of data that the user can specify:
| ACTIVE | Prompt for (or allow preselection of) type objects that are not locked. | |
| LOCK | Accept only type objects that are locked. | |
| OBSOLETE | Accept only type objects that are obsolete. (See the lock manual page.) |
%HYPERLINK[preselect-count]( ) preselector %HYPERLINK[]( prompt, browser ) macro |
Prompt for one or more hyperlink objects (see Table 18-6 and Example 18-2.)
Table 18-6. %HYPERLINK Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt |
|
browser | vtree element-pname [a] |
|
[a] Optional; if you omit it, user is prompted to select an element | ||
f.exec %QUOTE% cleartool rmhlink \ %HYPERLINK[](Select merge arrows to remove:,vtree %SELECTION()) %QUOTE% |
%LIST[preselect-count]( ) preselector %LIST[]( prompt, title ) macro |
Prompt for data from a named list browser (see Table 18-7 and Example 18-3.)
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt |
|
title | Title of list browser to use |
|
f.exec %QUOTE% %SAVE(COs,%LIST[](Select items to checkin:,My Checkouts)) cleartool checkin %RESTORE(COs) %QUOTE% |
Use %list to read list data from a named list browser, to which data was previously directed with %listout. (Only the %list macro can read the data in a list browser, and only %listout can create one.) The title argument must match the title used by %listout to create the list browser.
Use the %listout/%list combination when you need to display data and then have the user select from that data. The %listout and %list macros can appear in “back to back” f.exec scripts in the same item definition, or they can appear in separate item definitions — even in separate group files.
A list browser prompts the user to select one or more items (line of text). For each item, only the text preceding the first tab character is returned; any remainder is ignored. Pressing Ok submits the selection; pressing Cancel cancels the entire command operation. The user cannot edit the contents of a list browser.
%PNAME[preselect-count]( restrictions ) preselector %PNAME[]( prompt, restrictions, browser, keyboard ) macro |
Prompt (with file or vtree browser) for one or more pathnames (see Table 18-8.)
Table 18-8. %PNAME Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Select pathname(s) |
restrictions | DIR or NDIR ELEM or NELEM DOBJ or NDOBJ INVOB or NINVOB CHECKOUT or NCHECKOUT RESERVED or NRESERVED | don't care don't care don't care don't care don't care don't care |
browser | file dir-pname [a] or vtree element-pname [b] | file browser prompts for file in current directory |
keyboard | ENABLE | not enabled |
[a] file — dir-pname is optional; if you omit it, current working directory is used [b] vtree — element-pname is optional; if you omit it, user is prompted to select an element | ||
In Example 18-4, the File Browser comes up in /vobs/proj1/src, not in the current working directory.
f.exec %QUOTE% cleartool checkin \ %PNAME[](Files to checkin, NDIR ELEM INVOB CHECKOUT RESERVED, file /vobs/proj1/src) %QUOTE% |
Use the restrictions argument to limit the kind of data that the user can specify:
| dir | all pathnames must be directories | |
| ndir | all pathnames must not be directories | |
| elem | all pathnames must be elements | |
| nelem | all pathnames must not be elements | |
| dobj | all pathnames must be derived objects | |
| ndobj | all pathnames must not be derived objects | |
| invob | all pathnames must be within some VOB | |
| ninvob | all pathnames must not be within any VOB | |
| checkout | all pathnames must be checked-out elements | |
| ncheckout | all pathnames must not be checked-out elements | |
| reserved | all pathnames must be elements with reserved checkouts | |
| nreserved | all pathnames must not be elements with reserved checkouts |
%POOL[preselect-count]( ) preselector %POOL[]( prompt, pname-in-vob, keyboard ) macro |
Prompt for one or more storage pool names (see Table 18-9 and Example 18-5.)
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt |
|
pname-in-vob | Pathname in any VOB | VOB containing working dir |
keyboard | ENABLE | not enabled |
f.exec %QUOTE% cleartool chpool %POOL(Select new pool:,,ENABLE) %SELECTION() %QUOTE% |
%STRING[preselect-count]( ) preselector %STRING[]( prompt, default ) macro |
Prompt for one or more text lines (see Table 18-11 and Example 18-6.)
Table 18-10. %STRING Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Enter string |
default | Character string; pre-fills text input area |
|
f.exec %QUOTE% TAG='%STRING(Enter view tag name:)' STGPNAME='%WILD(%STRING(Enter view storage pathname:,""))' cleartool mkview -tag $TAG $STGPNAME %QUOTE% |
Use string browsers to prompt for simple text string arguments (for example, comments) or for other data strings— any data that cannot be captured by the more specific data type browsers.
If the %STRING macro includes square brackets, xclearcase may prompt the user for multiple lines of input. When the user presses Ok, the entire contents of the string browser is returned as a single text string: the last line is terminated with <NULL>; all other lines are terminated with <NL>.
%USERNAME[preselect-count]( ) preselector %USERNAME[]( prompt, keyboard ) macro |
Prompt for one or more usernames (see Table 18-11 and Example 18-7.)
Table 18-11. %USERNAME Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Select user name(s) |
keyboard | ENABLE | Not enabled |
f.exec %QUOTE% cleartool lscheckout -user \ %USERNAME(Specify a user:,ENABLE) %TEXTOUT() %QUOTE% |
%VIEWTAG[preselect-count]( restrictions ) preselector %VIEWTAG[]( prompt, restrictions, keyboard ) macro |
Prompt for one or more view-tags (see Table 18-9 and Example 18-8.)
Table 18-12. %VIEWTAG Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Select viewtag(s) |
restrictions | ACTIVE or INACTIVE | Don't care |
keyboard | ENABLE | not enabled |
f.exec %QUOTE% cleartool startview %VIEWTAG() %QUOTE% |
%VOBTAG[preselect-count]( restrictions ) preselector %VOBTAG[]( prompt, restrictions, keyboard ) macro |
Prompt for one or more VOB-tags (see Table 18-9 and Example 18-9.)
Table 18-13. %VOBTAG Input Macro
Argument | Values | Default |
|---|---|---|
prompt | Character string for user prompt | Select vobtag(s) |
restrictions | MOUNTED or NMOUNTED | Don't care |
keyboard | ENABLE | Not enabled |
f.exec %QUOTE% cleartool umount %VOBTAG(,MOUNTED,ENABLE) %QUOTE% |
![]() | Note: The default xclearcase interface implements this operation differently: |
%VOBTAG(MOUNTED) f.exec "cleartool umount %SELECTION()" |
Modifier macros take pathname arguments, perform some kind of data manipulation (expansion, extraction, sorting, etc.), and return the resultant text strings.
![]() | Note: Unlike input macro arguments, arguments to modifier macros are all required. |
%ELEMENT( pathnames ) macro |
Strip any ClearCase annotations from pathnames, leaving standard pathname (see Table 18-11 and Example 18-10.)
Table 18-14. %ELEMENT Modifier Macro
Argument | Values |
|---|---|
pathnames | Any pathname(s) (non-element pathnames are returned unchanges) |
f.exec %QUOTE% cleartool checkin %ELEMENT(%SELECTION()) %QUOTE% |
%ELEMSUFFIX( pathnames ) macro |
Append extended naming symbol (@@) to pathnames (see Table 18-11 and Example 18-11.)
Table 18-15. %ELEMSUFFIX Modifier Macro
Argument | Values |
|---|---|
pathnames | Any pathname(s) (non-element pathnames are returned unchanges) |
f.exec %QUOTE% cleartool lsvtree %ELEMSUFFIX( %ELEMENT( %PNAME(Element whose version tree is to be listed, INVOB ELEM))) %QUOTE% |
%MOUNT( pathnames ) macro |
Return the VOB mount points (VOB-tags) of specified pathnames (see Table 18-11 and Example 18-12.)
Table 18-16. %MOUNT Modifier Macro
Argument | Values |
|---|---|
pathnames | Any pathname(s) within one or more VOBs |
f.exec %QUOTE %TEXTOUT(Mount List,"No mounted VOBs specified",6,4) echo '%MOUNT(%PNAME[](Select VOB pathname%(s%),INVOB))' %QUOTE% |
The two parenthesis characters are escaped — %( and %) — to protect them from the macro expansion pass.
%RELATIVE( pathnames, dir ) macro |
Convert full or relative pathnames into pathnames relative to directory (see Table 18-11 and Example 18-13.)
Table 18-17. %RELATIVE Modifier Macro
Argument | Values |
|---|---|
pathnames | Any pathname(s) within one or more VOBs |
dir | The directory to which the converted pathnames are to be relative |
f.exec %QUOTE% #!/bin/sh PATH=$PATH:$HOME/%RELATIVE( %PNAME(Select a dir anywhere under your home dir),$HOME) %QUOTE% |
%SETVIEW( pathnames ) macro |
Convert pathnames to view-extended pathnames, based on the current set view (see Table 18-11 and Example 18-14.)
The example invokes a text editor on the selected file.
f.exec %QUOTE% %WHICH(GRP_PATH,editor.sh) %SETVIEW(%SELECTION()) %QUOTE% |
![]() | Note: If the argument is already a view-extended pathname, it is unchanged by %setview, regardless of the view-tag on which it is based. |
%SORT( pathnames ) macro |
Sort pathnames as shown in Table 18-11 and Example 18-15.
f.exec %QUOTE% echo '%SORT(%PNAME[]())' %TEXTOUT(Sorted Pnames,,8,4) %QUOTE% %VERMOD( pathnames ) macro |
Convert standard pathnames to version-extended pathnames (see Table 18-11 and Example 18-16.)
Table 18-20. %VERMOD Modifier Macro
Argument | Values |
|---|---|
pathnames | Any pathname(s) (non-element pathnames are returned unchanges) |
f.exec %QUOTE%
cleartool findmerge %SELECTION() -xmerge -log /dev/null \
-whynot -fver %VERMOD( %PNAME(
Select 'from' version: ['to' %VERMOD(%SELECTION())],ELEM INVOB,
vtree %SELECTION())
) | grep -v "Needs Merge" %TEXTOUT("Merge Info",,8,2)
%QUOTE%
|
%WHICH( path-ev, filename ) macro |
Search specified path for the first occurrence of filename (see Table 18-11 and Example 18-17.)
Table 18-21. %WHICH Modifier Macro
Argument | Values |
|---|---|
path-EV | Any environment variable that stores a directory search path (typically, grp_path) |
filename | Any valid file name (a shell script or executable) |
f.exec %QUOTE% %WHICH(GRP_PATH,editor.sh) %SETVIEW(%SELECTION()) %QUOTE% |
Like the unix which(1) command, %which returns (by searching path-EV) the full pathname of its filename argument. The %which macro exists to help support local customizations to the ClearCase-supplied .sh scripts that are installed in /usr/atria/config/ui/grp.
The ClearCase-supplied group files include a number of f.exec scripts that invoke .sh files to perform specialized processing — finding and invoking the user's preferred text editor, for example. To customize a .sh file, first copy it to another directory. Make sure this directory occurs in the path-EV, and use %which to invoke your customized file.
For example, suppose you copy the file term_display.sh to $home/.grp and customize it. If your grp_path variable is set to $home/.grp:/usr/atria/config/ui/grp (which is the default), then the macro %WHICH(GRP_PATH,term_display.sh) finds and executes your version.
%WILD( pathnames ) macro |
Expand wildcards in pathnames (see Table 18-11 and Example 18-18.)
Table 18-22. %WILD Modifier Macro
Argument | Values |
|---|---|
path-expr | Pathname with one or more of these wildcard characters: |
f.exec %QUOTE% %PNAME(%WILD(%STRING())) %QUOTE% |
By default, the output generated by menu commands is collected in the transcript pad. The %listout and %textout macros redirect standard output to a list browser or read-only text window, respectively.
Both %textout and %listout redirect output for the entire f.exec operation, regardless of their location in the script. Either macro “expands” to the null string in the script; output redirection is established during the macro expansion “pre-pass”.
%LISTOUT( title, class, persistence, width, height ) macro |
Redirect output to a list browser (named or unnamed) (see Table 18-11 and Example 18-19.)
Table 18-23. %LISTOUT Output Macro
Argument | Values | Default |
|---|---|---|
title | Character string | Enter string |
class | Character string | class of active browser when macro invoked |
persistence | TRANSIENT | browser stays up until user closes it |
width | 1-32 (window width in inches) | 8 |
height | 1-32 (window height in inches) | 4 |
f.exec %QUOTE% cleartool lsch -short . %LISTOUT(VOB Checkouts,,,6,4) %QUOTE% |
Use %listout to capture lists of pathnames or other VOB objects into a named list browser, from which data can later be selected (see %list) and supplied to other operations.
The title argument gives the list browser a name, which %list then uses to refer to the browser when using it to collect user input.
The optional class argument specifies a list browser class. You can scope a group file to a list browser class (giving the class an arbitrary name: Scope myList:toolbar, for example), thereby providing a set of menu items for the user to choose from when such a list browser is displayed. The group file menu appears on any list browser that %listout creates with the applicable class argument.
List data entries are separated or terminated by <nl> or null characters. Furthermore, within a single list entry (one line), only the text before the first tab character is returned by %list; the rest is ignored.
By default, a list browser created with %listout stays up until the user closes it. The TRANSIENT argument forces the list browser to close after either:
a %list macro generates a prompt in that list browser, and the user responds to the prompt by pressing Ok or Cancel, or
the menu item's command operation completes.
%TEXTOUT( title, default-text, width, height ) macro |
Redirect standard output to read-only text-display window (see Table 18-11 and Example 18-20.)
Table 18-24. %TEXTOUT Output Macro
Argument | Values | Default |
|---|---|---|
title | Title of text browser |
|
default-text | Character string |
|
width | 1-32 (window width in inches) | 8 |
height | 1-32 (window height in inches) | 4 |
f.exec %QUOTE%
%TEXTOUT("Describe",,8,2)
cleartool lstype -attype -long %SELECTION() 2>&1"
%QUOTE%
|
Unlike %listout, %textout redirects the standard output of commands to an untyped, read-only text window. Use %textout when your only objective is to display information.
The default text argument (def-text) specifies text to be displayed if the redirected operations generate no output.
Like %listout, %textout redirects stdout for the entire f.exec script. To redirect both stderr and stdout for a given command, use the /bin/sh construct 2>&1.
For comparison with list browsers, Figure 18-15 shows a sample text output window, and Figure 18-16 shows a terminal emulation window. Neither prompts for, or accepts, user input; they are display-only devices.
The text output window was generated by the Describe button and the terminal window by menu item Report -> Find query -> Whole VOB -> Versions with Label...
You can cancel output to a terminal emulation window with <Ctrl-C>.
Use the %save and %restore macros to mimic user-defined shell variables inside other xclearcase macros. Because xclearcase simply expands macros into strings (before running the execution script), you cannot use shell variables or other shell constructs inside macros. However, in an f.exec script, you can use %save to store and name an arbitrary string. Later in the same script — or in a subsequent f.exec script — you can use %restore to apply the saved string in a command line (including inside an xclearcase macro).
By default, the temporary storage is release when the f.exec script terminates. Use the KEEP argument to retain the temporary variable until either (a) it is released by a %remove macro, or (b) the xclearcase session terminates.
%SAVE( var-name, string, persistence ) macro |
Save string into named temporary variable (can be referenced with %RESTORE (see Table 18-11 and Example 18-21.))
Table 18-25. %SAVE Memory Macro
Argument | Values | Default |
|---|---|---|
var-name | Name of temporary variable | Enter string |
string | Character string to be stored in variables |
|
persistence | KEEP | variable removed after this f.exec completes |
f.exec %QUOTE% %SAVE(dir, %PNAME(Select target dir, DIR INVOB),KEEP) . . DIR='%RESTORE(dir)' %REMOVE(dir) %QUOTE% |
%REMOVE( var-name ) macro |
Delete a persistent temporary variable created with %SAVE (see Table 18-11 and Example 18-22.)
f.exec %QUOTE% %SAVE(tmp_print_file, %TMPFILE(), KEEP) . . %REMOVE(tmp_print_file) %QUOTE% |
%RESTORE( var-name ) macro |
Retrieve the value of a temporary variable created with %SAVE (see Table 18-11 and Example 18-23.)
f.exec %QUOTE% %SAVE(dir, %PNAME(Select target directory, DIR INVOB)) . . DIR='%RESTORE(dir)' %QUOTE% |
These macros take no arguments.
%SELECTION( ) macro |
Return the current data selection(s) from the current browser (see Example 18-24.)
f.exec %QUOTE% cleartool uncheckout -rm %SELECTION() %QUOTE% |
The %selection() macro is replaced by the data that has been preselected by the user. %selection() can appear only in items in which the f.exec strings is preceded by an activation clause.
%DIR( ) macro |
Return the pathname of the current browser's directory (see Example 18-25.)
f.exec %QUOTE% echo "Current working dir is %DIR()" %QUOTE% |
%NAME( ) macro |
Return the name associated with the current browser (see Example 18-26.)
f.exec %QUOTE% %WHICH(GRP_PATH,term_display.sh) USE_MORE \ cleartool lshistory -long %NAME() %QUOTE%" |
For a vtree browser, expands to name of the element whose vtree is displayed. For all other browsers, expands to the current directory pathname.
%TMPFILE( ) macro |
Create a temporary file and return its pathname (see Example 18-27.)
f.exec %QUOTE% %SAVE(tmp_print_file, %TMPFILE(), KEEP) %QUOTE% |
This example creates a temporary file in $TMPDIR (or /usr/tmp, if this EV is not set). The full pathname of the temporary file is placed in the xclearcase variable tmp_print_file.
Customization tasks fall into two general categories:
add a new menu
replace an existing menu
Here are the basic procedures for accomplishing each task.
Copy to your work area (typically, $home/.grp) the predefined group file template /usr/atria/config/ui/grp/user.grp.template, which is a syntax skeleton. Rename the file to user.grp, or to some other name with a .grp suffix.
Determine a scope for your new menu (Fast:pulldown, Vtree:pulldown, or File:pulldown, for example).
The template group file defaults to Fast:pulldown scope. This positions the new menu on the file browser's Fast pulldown menu and, optionally, as a set of buttons on the file browser toolbar. See “Scope” for more details.
Replace the template group file's menu item definitions with your own. Copy and modify an item definition from one of the ClearCase-supplied group files (ideally, one that does some or all of the desired operation).
Each item definition must include at least a label (or no-label) and an f-dot function. (Most will include one or more f.exec scripts.) For a pull-down or pop-up menu item, it is good practice to add a menu mnemonic and, when applicable, a preselect clause. For a toolbar button, you may wish to add bitmap icons. If your menu will be used by others, supply f.help strings for all menu items.
Before attaching a complex script to a menu item, see “Complex Execution Scripts”, below.
Restart xclearcase and test the new menu items.
Because the group files are read once at startup time and cached, you must exit and restart xclearcase to activate any group file changes. In general, a menu is ignored (it does not appear in the interface) if its group file contains syntax errors; check the transcript pad for diagnostic messages.
By default, /bin/sh is used to execute your f.exec scripts. Include a first line like #!/bin/csh to specify another shell.
![]() | Note: If you set the environment variable clearcase_dbg_grp to a non-zero value, xclearcase sends debugging information to the transcript pad when executing commands. |
Find the ClearCase-supplied .grp file you want to customize (typically, to add new items) and copy it to $home/.grp, or to any directory in your grp_path that precedes /usr/atria/config/ui/grp. Because xclearcase ignores any group file with the same name as one already scanned in, your copied group file now “eclipses” the standard group file.
Add your own item definitions.
![]() | Note: Although you are now in a position to modify the predefined menu items, this is not advised. Such customizations are equivalent to modifying the source code, and have the potential to leave you “out of sync” with future ClearCase-supplied enhancements and bug fixes to the standard group files. |
Restart xclearcase and test each new menu item.
The technique described here is recommended if you are attaching either of the following to a menu item:
a complex operation
an operation that must be repeated for multiple menu items
Code the “meat” of the operation as a standard shell script (no ClearCase macros), and invoke the script from an f.exec script using the %which macro. The %which macro is described on page 275. The ClearCase-supplied group files include numerous examples of this technique (calling the various .sh scripts installed in /usr/atria/config/ui/grp).
For example, the following item definition includes an f.exec script that calls print_file.sh to find a print command and then print the preselected files:
"Print" _P %PNAME[](NDIR) & \
f.exec %QUOTE%
%WHICH(GRP_PATH,print_file.sh) %SETVIEW(%SELECTION())
%QUOTE% \
f.help "Print the selected files."
|
![]() | Note: “external” scripts cannot use xclearcase macros to collect input and, therefore, must use clearprompt or some other mechanism to do so. |
ClearCase provides a number of predefined color and font combinations for use with the graphical interface. Each predefined collection of resources is called a scheme. See the schemes manual page for details.
![]() | Note: The scheme files commonly set specific widget class resources. Therefore, xclearcase command line options (for example, -bg and -fg) may not work as expected, because they set resources at the most general level. You have the option to disable schemes, to modify them, or to set still more specific resources. |
A file browser can display file system objects either by-name or graphically. In the latter case xclearcase selects an icon for each file system object as follows:
In a process described in the cc.magic manual page, xclearcase uses an object's name, and/or its contents, to compile a list of one or more file types that correspond to the object.
One by one, the file types are compared to the rules in predefined and user-defined icon files, as described in the cc.icon manual page. For example, the file type c_source matches this icon file rule:
c_source : -icon c ; |
As soon as a match is found, the search ends. The token following -icon identifies the icon's bitmap file.
By default, xclearcase searches first for the bitmap file (which must be in bitmap(1) format) in the .bitmaps subdirectory of your home directory, then in /usr/atria/config/ui/bitmaps. If the bitmap_path variable is set, xclearcase searches the directories there instead.
If a valid bitmap file is found, xclearcase displays it; otherwise, the search for an icon continues with the next file type.
The name of an icon file should include a numeric suffix, which need not be specified in the icon file rule. The suffix tells xclearcase how much screen space to allocate for the icon. Each bitmap supplied with ClearCase is stored in a file with a .60 suffix (for example, lib.60), indicating a 60x60 icon.
The following steps install a customized icon for unix-style manual page source files.
Add a rule to your personal magic file ($home/.magic) that includes manpage among the file types assigned to all manual page source files:
manpage src_file text_file file: -name "*.[1-9]" ;
|
Add a rule to your personal icon file (in directory $home/.icon) that maps manpage to a user-defined bitmap file:
manpage : -icon manual_page_icon ; manpage : -icon manual_page_icon ;
|
Create a manpage icon in your personal bitmaps directory ($home/.bitmaps) by revising one of the standard icon bitmaps with the X bitmap utility:
% mkdir $HOME/.bitmaps % cd $HOME/.bitmaps % cp /usr/atria/config/ui/bitmaps/c.60 manual_page_icon.60 % bitmap manual_page_icon.60 |
Test your work by having an xclearcase file browser display a manual page source file (Figure 18-17).