Using Variables in Action and Data Type Definitions

You can include string variables and environment variables in action and data type definition files.

Using String Variables in an Action

A string variable definition remains in effect from the location of the definition to the end of the file. There are no global string variables for the database.

If a string variable and environment variable have the same name, the string variable has precedence.

To Define a String Variable

• Use the syntax:

	set variable_name=value

Variable names can contain any alphanumeric characters and underscore (_). Each variable definition must be on a separate line.

For example:

set Remote_Application_Server=sysapp
set Remote_File_Server=sysdata

To Reference a String Variable

• Use the syntax:

	$[{]variable_name[}]

For example:

EXEC-HOST			$Remote_Application_Server
CWD					/net/${Remote_File_Server}/doc/project

Using Environment Variables in Actions and Data Types

• Reference an environment variable using the syntax:

	$[{]variable[}]. 

The variable is expanded (replaced by its value) when the database is loaded. If a string variable and environment variable have the same name, the string variable has precedence.

For example, this execution string prints a file with a banner containing the login name.

EXEC-STRING lp -t$LOGNAME %(File)Arg_1%

Invoking Actions from a Command Line

The desktop provides the dtaction command for running actions from a command line. You can use dtaction to run actions from:

• Scripts

• Other actions

• A terminal emulator command line

Syntax of dtaction

dtaction [-user user_name] [-execHost hostname] \
 action_name [argument [argument]...]

-user user_name--provides the ability to run the action as a different user. If dtaction is invoked by a user other than user_name, a prompt is displayed for the password.

-execHost hostname--for COMMAND actions only; specifies the host on which the command will be run.

argument--arguments to the action; usually file arguments.

The dtaction client has additional command-line options. For more information, see the dtaction(1) man page.

Creating an Action that Runs Another Action

Use dtaction in the EXEC_STRING of the action.

For example, the following action uses a built-in action named Spell (the action is labeled ``Check Spelling'' in Application Manager). The new action runs Text Editor and the Spell action, displaying the spelling errors in a separate terminal emulator window.

ACTION EditAndSpell
 {
 	WINDOW_TYPE				NO_STDIO
 	EXEC_STRING				/bin/sh -c 'dtaction Spell \
 								%Arg_1"File:"%; dtpad %Arg_1%'
 }

Creating an Action that Runs as a Different User

Use the following syntax in the EXEC_STRING:

EXEC_STRING   dtaction -user user_name action_name [file_argument]

The new user (user_name) must have display access to the system through one of the following mechanisms:

• Read permission on the login user's .Xauthority file

• Or, xhost permission

  For example, the following two actions provide the ability to become root and edit an app-defaults file.

  ACTION AppDefaults { WINDOW_TYPE NO_STDIO EXEC_STRING /usr/dt/bin/dtaction -user root \ EditAppDefaults %Arg_1"File:"% } ACTION EditAppDefaults { WINDOW_TYPE TERMINAL EXEC_STRING /bin/sh -c 'chmod +w %Arg_1%; \ vi %Arg_1%; chmod -w %Arg_1%' }

Creating Localized Actions

The search path for data types includes language-dependent locations. The desktop uses the value of LANG to determine the locations searched for data type definitions.

Locations for Localized Actions

Localized action definitions must be placed in the proper language-dependent directories along the actions search path.

The default search path is:

• Personal actions: HomeDirectory/.dt/types

• System-wide actions: /etc/dt/appconfig/types/language

• Built-in actions: /usr/dt/appconfig/types/language