# Creating Actions Manuallyactionscreating manually

There are two ways to create actions:

- Using the Create Action desktop application

- Manually creating an action definition

Creating an action manually requires you to edit a database file. This chapter describes how to manually create action definitions.

SAG.CrAct.div.3
SAG.CrAct.div.7
SAG.CrAct.div.19
SAG.CrAct.div.40
SAG.CrAct.div.44
SAG.CrAct.div.49
SAG.CrAct.div.52
SAG.CrAct.div.57
SAG.CrAct.div.61
SAG.CrAct.div.64

## See Also

- For an introduction to actions, see SAG.IntAc.mkr.1.

- For information about using Create Action, see SAG.dtCrA.mkr.1.

- For reference information about action definitions, see the `dtactionfile(4)` man page.

## Reasons You Must Create an Action Manually

There are three basic types of actions:

- `COMMAND`

- `MAP`

- `TT_MSG`

The Create Action tool is designed to create certain types of `COMMAND` and `MAP` actions. All `TT_MSG` actions must be created manually.

For more information, see SAG.dtCrA.mkr.3.

### COMMAND Actions

A command action executes a command that starts an application or utility, runs a shell script, or executes an operating system command. The definition of the action includes the command to be executed (the `EXEC_STRING`).

The Create Action tool can be used to create the most common types of command actions. However, there may be some situations where you must create the action manually; for example, you must create a `COMMAND` action manually if the action specifies:

- Multiple-file arguments with a different prompt for each argument.

- Action invocation—the ability of actions to invoke other actions.

- Argument-count dependent behavior—the ability to create an action that has very different behaviors for different numbers of file arguments.

- A remote execution host—the ability to run an application on a system other than the one containing the action definition.

- Change of user—the ability to run the action as a different user (for example, to prompt for the root password and then run as root).

### MAP Actions

A map action is an action that is ``mapped'' to another action rather than directly specifying a command or ToolTalk message

Mapping provides the ability to specify alternative names for actions. For example, a built-in command action named IconEditor starts Icon Editor. The database also includes an Open action, restricted in the definition to bitmap and pixmap files (by the `ARG_TYPE` field), that is mapped to the IconEditor action. This lets the user start Icon Editor by selecting a bitmap or pixmap file in File Manager and then choosing Open from the Selected menu.

Create Action provides limited mapping for Open and Print actions. All other map actions must be created manually.

### TT_MSG (ToolTalk Message) Actions

`TT_MSG` actions send a ToolTalk message. All `TT_MSG` actions must be created manually.

## Creating an Action Manually: General Steps

This section explains how to create a configuration file for an action definition.

### Configuration Files for Actions

Configuration files containing action definitions must meet these requirements:

- The files must use the naming convention name`.dt`

- The files must be located on the database (actions and data types) 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. You should not use this directory.

For information on modifying the actions/data types search path, see SAG.Datab.mkr.6.

### To Create an Action Manually

1. Open an existing database file or create a new one. See the previous section, SAG.CrAct.mkr.5.

2. Create the action definition using the syntax:

       ACTION action_name
       {
        TYPE action_type
        action_field
        …
       }

   where:

   action_name | Name used to run the action.
   action_type | `COMMAND` (default), `MAP`, or `TT_MSG.`
   action_field | One of the required or optional fields for this type of action. All fields consist of a keyword and a value. Many of the action fields are covered in this chapter. For more information, see the dtactionfile(4) man page.

3. Save the file.

4. If you want the action icon to have a unique image, create the icons for the action. The default location for icons is:

   - Personal icons: HomeDirectory`/.dt/icons`

   - System-wide icons: `/etc/dt/appconfig/icons/`language. The default language is `C`.

     For more information, see SAG.FrPC.div.25.

5. Double-click Reload Actions in the Desktop_Tools application group.

6. Create an action file for the action. The action file creates an icon in File Manager or Application Manager that represents the action. (If the action is written to start an application, the icon is called an
   application icon.)

   To create the action file, create an executable file with the same name as action_name. You can put the file in any directory to which you have write permission. You can create as many action files as you like.

### Example of Creating a COMMAND Action

The following steps create a personal action that starts a fax application on remote system AppServerA. The command for starting the fax application is:

    /usr/fax/bin/faxcompose [filename]

1. Create the file HomeDirectory`/.dt/types/Fax.dt`.

2. Put the following action definition into the file:

       ACTION FaxComposer
       {
        TYPE         COMMAND
        ICON         fax
        WINDOW_TYPE  NO_STDIO
        EXEC_STRING  /usr/fax/bin/faxcompose -c %Arg_1%
        EXEC_HOST       AppServerA
        DESCRIPTION  Runs the fax composer
       }

   The `WINDOW_TYPE` and `EXEC_STRING` fields describe the behavior of the action.

   `WINDOW_TYPE` | The `NO_STDIO` keyword specifies that the action does not have to run in a terminal emulator window. See SAG.CrAct.div.41.
   `EXEC_STRING` | The syntax `%Arg_1%` accepts a dropped file. If the action icon is double-clicked, the action opens an empty fax composer window. See SAG.CrAct.div.19.

3. Save the file.

4. Use Icon Editor to create the following image files in the HomeDirectory`/.dt/icons` directory:

   - `fax.m.pm`, size 32 by 32 pixels

   - `fax.t.pm`, size 16 by 16 pixels

5. Double-click Reload Actions in the Desktop_Tools application group.

6. Create an executable file named `FaxComposer` in a directory to which you have write permission (for example, your home directory).

### Example of Creating a MAP Action

Suppose most of the files you fax are created with Text Editor and are of data type TEXTFILE (files named *`.txt`).

These steps add a ``Fax'' menu item to the data type's Selected menu.

1. Open the file HomeDirectory`/.dt/types/Fax.dt` that was created in the previous example.

2. Add this map action definition to the file:

       ACTION Fax
       {
        ARG_TYPE    TEXTFILE
        TYPE        MAP
        MAP_ACTION  FaxComposer
       }

3. Save the file.

4. Copy the data attributes definition for TEXTFILE from /`usr/dt/appconfig/types/`language`/dtpad.dt` to a new file HomeDirectory`/.dt/types/textfile.dt`. Add the Fax action to the `ACTIONS` field.

       DATA_ATTRIBUTES TEXTFILE
       {
        ACTIONS  Open,Print,Fax
        ICON     Dtpenpd
        …
       }

5. Save the file.

6. Open Application Manager and double-click Reload Actions in the Desktop_Tools application group.

### To Reload the Actions/Data Types Database

In order for new or edited action definitions to take effect, the desktop must reread the database.

1. Open the Desktop_Tools application group and double-click Reload Actions.

2. Or, execute the command:

       dtaction ReloadActions

ReloadActions is the name of the action whose icon is labeled ``Reload Actions.''

The actions database is also reread when the user:

- Logs in

- Restarts the Workspace Manager

- Saves an action in the Create Action window by choosing Save from the File menu

### Creating an Action File (Icon) for an Action

An
action file is a file created to provide a visual representation of the action in File Manager or Application Manager.

#### Action files (also called action icons or application icons) in Application Manager

Since an action file's icon represents an action, it is sometimes called an
action icon. If the underlying action starts an application, the action file icon is called an application icon.

Double-clicking the action icon runs the action. The action icon may also be a drop zone.

#### To Create an Action File (Action Icon)

1. Create an executable file with the same name as the
   action name. The content of the file does not matter.

For example, if the action definition is:

    ACTION  MyFavoriteApp
    {
     EXEC_STRING    Mfa -file %Arg_1%
     DESCRIPTION    Runs MyFavoriteApp
     ICON           Mfapp
    }

then the action file would be an executable file named `MyFavoriteApp`. In File Manager and Application Manager, the `MyFavoriteApp` file would use the icon image `Mfapp.`size`.`type. Double-clicking `MyFavoriteApp`'s icon would run the action's execution string, and the icon's On Item help would be the contents of the `DESCRIPTION` field (`Runs MyFavoriteApp`).

#### Action Labels

If the action definition includes the `LABEL` field, the action file will be labeled in File Manager and Application Manager with the contents of this field rather than the file name (action_name). For example, if the action definition includes:

    ACTION  MyFavoriteApp
    {
     LABEL      Favorite Application
     …
    }

then the action icon will be labeled ``Favorite Application.''

### Specifying the Icon Image Used by an Action

Use the `ICON` field to specify the icon used in File Manager and Application Manager for the action icons created for the action.

If you do not specify an icon, the system uses the default action icon
image files `/usr/dt/appconfig/icons/`language`/Dtactn.*`.

#### Default action icon image

The default action icon can be changed using the resource:

    *actionIcon:    icon_file_name

where icon_file_name can be a base name or absolute path.

The value of the `ICON` field can be:

- A base file name.

  The
  base file name is the name of the file containing the icon image minus the file-name suffixes for size (`m` and `t`) and image type (`bm` and `pm`). For example, if files are named `GameIcon.m.pm` and `GameIcon.t.pm`, use `GameIcon`.

  If you use the base file name, the icon files must be placed in a directory on the icon search path:

  - Personal icons: HomeDirectory`/.dt/icons`

  - System-wide icons: `/etc/dt/appconfig/icons/`language

- An absolute path to the icon file, including the full file name.

  You should use the absolute path only if the icon file is not located on the icon search path. For example, if icon file `GameIcon.m.pm` is placed in the directory `/doc/projects`, which is not on the icon search path, the value of the `ICON` field would be `/doc/projects/GameIcon.m.pm`.

SAG.CrAct.tbl.1 lists icon sizes you should create and the corresponding file names.

### Icon Names and Sizes for Action Icons

`Size in Pixels` | `Bitmap Name` | `Pixmap Name`
48 by 48 | name`.l.bm` | name`.l.pm`
32 by 32 | name`.m.bm` | name`.m.pm`
16 by 16 | name`.t.bm` | name`.t.pm`

### To Modify an Existing Action Definition

You can modify any of the actions available on your system, including built-in actions.

Use caution when modifying the built-in action database. The built-in actions are designed to work well with the desktop applications.

1. Locate the definition of the action you want to modify.

   The default locations for action definitions are:

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

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

   - Personal actions: HomeDirectory`/.dt/types`

     Your system might include additional locations. To see a list of the locations your system uses for actions, execute the command:

         dtsearchpath -v

     Your system uses the directories listed under
     DTDATABASESEARCHPATH.

2. If necessary, copy the text of the action definition to a new or existing file in one of these directories:

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

   - Personal actions: HomeDirectory`/.dt/types`

     You must copy built-in actions, since you should not edit files in the `/usr/dt/appconfig/types/`language directory.

3. Edit the action definition. When you are done, save the file.

4. Double-click Reload Actions in the Desktop_Tools application group.

### Precedence in Action Definitions

When the user invokes an action, the system searches the database for a matching action name. When more than one action exists with that name, the system uses precedence rules to decide which one to use.

- If no other precedence rules apply, the precedence is based on the location of the definition. The following list is ordered from higher to lower precedence:

  - Personal actions (HomeDirectory`/.dt/types`)

  - System-wide local actions (`/etc/dt/appconfig/types/`language)

  - System-wide remote actions (hostname:`/etc/dt/appconfig/types/`language). The remote hosts searched are those listed in the application search path.

  - Built-in actions (`/usr/dt/appconfig/types/`language)

- Within a given directory, the `*.dt` files are read in alphabetical order.

- Actions restricted by `
  ARG_CLASS`, `
  ARG_TYPE`, `
  ARG_MODE`, or `
  ARG_COUNT` have precedence over unrestricted actions. (The default for these four fields is `*`.)

  Where more than one restriction applies, the precedence order from high to low is:

  - `ARG_CLASS`

  - `ARG_TYPE`

  - `ARG_MODE`

  - `ARG_COUNT`

  Where more than one restricted `ARG_COUNT` exists, the precedence order from high to low is:

  - Specific integer value n

  - `<`n

  - `>`n

  - `*`

For example, consider the following portions of action definitions:

    ACTION EditGraphics
    # EditGraphics-1
    {
     ARG_TYPE    XWD
     …
    }
    ACTION EditGraphics
    # EditGraphics-2
    {
     ARG_COUNT      0
     …
    }
    ACTION EditGraphics
    # EditGraphics-3
    {
     ARG_TYPE    *
        …
    }

Double-clicking the EditGraphics action icon starts EditGraphics-2 because no argument is provided and `ARG_COUNT` `0` has precedence. When an XWD-type file argument is provided, EditGraphics-1 is used because it specified the XWD `ARG_TYPE`. EditGraphics-3 is used for all other file arguments.

## Building the Execution String for a COMMAND Action

The minimum requirements for a `
COMMAND` action are two fields—`ACTION` and `EXEC_STRING`.

    ACTION action_name
    {
        EXEC_STRING execution_string
    }

The execution string is the most important part of a `COMMAND` action definition. It uses syntax similar to the command line you would execute in a Terminal window but includes additional syntax for handling file and string arguments.

### General Features of Execution Strings

Execution strings may include:

- File and non-file arguments

- Shell syntax

- Absolute paths or names of executables

#### Action Arguments

An argument is information required by a command or application for it to run properly. For example, consider the command line you could use to open a file in Text Editor:

    dtpad filename

In this command filename is a file argument of the `dtpad` command.

Actions, like applications and commands, can have arguments. There are two types of data that a `COMMAND` action can use:

- Files

- String data

#### Using Shells in Execution Strings

The execution string is executed directly, rather than through a shell. However, you can explicitly invoke a shell in the execution string.

For example:

    EXEC_STRING    \
      /bin/sh -c \
      'tar -tvf %(File)Arg_1% 2>&1 | \${PAGER:-more};\
      echo “\\n*** Select Close from the Window menu to close ***”'

#### Name or Absolute Path of the Executable

If your application is located in a directory listed in the
PATH variable, you can use the simple executable name. If the application is elsewhere, you must use the
absolute path to the executable file.

### Creating an Action that Uses No Arguments

Use the same syntax for the `EXEC_STRING` that you would use to start the application from a command line.

#### Examples

- This execution string is part of an action that starts the X client `xcutsel`.

      EXEC_STRING xcutsel

- This execution string starts the client `xclock` with a digital clock. The command line includes a command-line option but requires no arguments.

      EXEC_STRING xclock -digital

### Creating an Action that Accepts a Dropped File

Use this syntax for the file argument:

    %Arg_n%

or

    %(File)Arg_n%

`(File)` is optional, since arguments supplied to `Arg_`n are assumed (by default) to be files. (See SAG.CrAct.div.31 for use of the `%(String)Arg_`n`%` syntax.)

This syntax lets the user drop a data file object on the action icon to start the action with that file argument. It substitutes the nth argument into the command line. The file can be a local or remote file.

#### Examples

- This execution string executes `wc -w` using a dropped file as the parameter.

      EXEC_STRING wc -w %Arg_1%

- This example shows a portion of a definition for an action that works only with directory arguments. When a directory is dropped on the action icon, the action displays a list of all the files in the directory with read-write permission.

      ACTION  List_Writable_Files
      {
          ARG_TYPE     FOLDER
          EXEC_STRING  /bin/sh -c 'ls -l %Arg_1% | grep rw-'
          …
      }

### Creating an Action that Prompts for a File Argument

Use this syntax for the file argument:

    %(File)“prompt”%

This syntax creates an action that displays a prompt for a file name when the user double-clicks the action icon.

For example, this execution string displays a dialog box that prompts for the file argument of the `wc -w` command:

    EXEC_STRING wc -w %(File)“Count words in file:”%

### Creating an Action that Accepts a Dropped File or Prompts for One

Use this syntax for the file argument:

    %Arg_n“prompt”%

or

    %(File)Arg_n“prompt”%

This syntax produces an action that:

- Accepts a dropped file as the file argument.

- Displays a dialog box that prompts for a file name when the user double- clicks the action icon.

For example, this execution string performs `lp` `-oraw` on a dropped file. If the action is started by double-clicking the icon, a dialog box appears prompting for the file name.

    EXEC_STRING lp -oraw %Arg_1“File to print:”%

### Creating an Action that Prompts for a Non-File Argument

Use this syntax for the non-file parameter:

    %“prompt”%

or

    %(String)“prompt”%

`(String)` is optional, since quoted text is interpreted, by default, as string data. This syntax displays a dialog box that prompts for non-file data; do not use this syntax when prompting for a file name.

For example, this execution string runs the `xwd` command and prompts for a value to be added to each pixel:

    EXEC_STRING xwd -add %“Add value:”% -out %Arg_1“Filename:”%

### Interpreting a File Argument as a String

Use this syntax for the argument:

    %(String)Arg_n%

For example, this execution string prints a file with a banner containing the file name, using the command `lp -t` banner filename.

    EXEC_STRING lp -t%(String)Arg_1% %(File)Arg_1“File to print:”%

### Providing Shell Capabilities in an Action

Specify the shell in the execution string:

    /bin/sh -c 'command'
    /bin/ksh -c 'command'
    /bin/csh -c 'command'

#### Examples

- This execution string illustrates an action that uses shell piping.

    EXEC_STRING /bin/sh -c 'ps | lp'

- This is a more complex execution string that requires shell processing and accepts a file argument.

    EXEC_STRING /bin/sh -c 'tbl %Arg_1“Man Page:”% | troff -man'

- This execution string requires that the argument be a compressed file. The action uncompresses the file and prints it using `lp -oraw`.

    EXEC_STRING  /bin/sh -c 'cat %Arg_1 “File to print:“% | \
                 uncompress | lp -oraw'

- This execution string starts a shell script.

    EXEC_STRING /usr/local/bin/StartGnuClient

### Creating COMMAND Actions for Multiple File Arguments

There are three ways for actions to handle multiple file arguments:

- The action can be run repreatedly, once for each argument. When an `EXEC_STRING` contains a single file argument and multiple file arguments are provided by dropping multiple files on the action icon, the action is run separately for each file argument.

  For example if multiple file arguments are supplied to the following action definition:

      ACTION DisplayScreenImage
      {
       EXEC_STRING  xwud -in %Arg_1%
       …
      }

  the DisplayScreenImage action is run repeatedly.

- The action can use two or more non-interchangeable file arguments. For example:

      xsetroot -cursor cursorfile maskfile

  requires two unique files in a particular order.

- The action can perform the same command sequentially on each file argument. For example:

      pr file [file …]

  will print one or many files in one print job.

#### Creating an Action for Non-Interchangeable Arguments

Use one of the following syntax conventions:

- If you want the action to prompt for the file names, use this syntax for each file argument:

      %(File)“prompt”%

  Use a different prompt string for each argument.

  For example, this execution string prompts for two files.

      EXEC_STRING  xsetroot -cursor %(File)“Cursor bitmap:”% \
                   %(File)“Mask bitmap:”%

- To accept dropped files, use this syntax for each file argument:

      %Arg_n%

  using different values of n for each argument. For example:

      EXEC_STRING  diff %Arg_1% %Arg_2%

#### Creating an Action with Interchangeable File Arguments

Use one of the following syntax conventions:

- To create an action that accepts dropped files and issues a command in the form command file 1 file 2 …, use this syntax for the file arguments:

      %Args%

- To create an action that accepts multiple dropped files, or displays a prompt for a single file when double-clicked, use this syntax for the file arguments:

      %Arg_1“prompt”% %Args%

  The action will issue the command in the form: command file 1 file 2 ….

##### Examples

- This execution string creates an action that executes:

      pr file1 file2

  with multiple file arguments.

      EXEC_STRING pr %Args%

- This execution string creates an action similar to the previous example, except that the action displays a prompt when double-clicked (no file arguments).

    EXEC_STRING  pr %Arg_1“File(s) to print:”% %Args%

#### Creating an Action for Multiple Dropped Files

To accept multiple dropped file arguments and execute a command line in the form:

    command file1 file2 …

use the syntax:

    %Args%

##### Examples

- This execution string executes a script named Checkout for multiple files:

    EXEC_STRING  /usr/local/bin/Checkout \
                 %Arg_1“Check out what file?”% %Args%

- This execution string executes `lp -oraw` with multiple files:

    EXEC_STRING  lp -oraw %Arg_1“File to print:”% %Args%

## Windowing Support and Terminal Emulators for COMMAND Actions

There are several ways that `COMMAND` actions support windows on the desktop.

- If the application has its own window, the action can be written to provide no additional window support. This option is also used when an action runs a command that requires no direct user input and has no output.

- If the application must run in a terminal emulator window, the action can be written to open a window and then run the application. There are several terminal options.

### Specifying the Window Support for the Action

Use the `WINDOW_TYPE` field to specify the type of windowing support required by the action.

WINDOW_TYPE | Windowing Support Provided
`NO_STDIO` | None. Use `NO_STDIO` if the application has its own window, or if the command has no visible output.
`PERM_TERMINAL` | Permanent terminal emulator window. The action opens a terminal window that remains open until the user explicitly closes it. The user can enter data into the window. Use with commands that take some input, produce some output, then terminate (for example, `ls` directory).
`TERMINAL` | Temporary terminal emulator window. The action opens a terminal window that closes as soon as the command is completed. Use with full-screen commands (for example, `vi`).

### Specifying Command-Line Options for the Terminal Emulator

Use the `TERM_OPTS` field in the action definition to specify command-line options for the terminal emulator.

For example, the following action prompts for the execution host:

    ACTION OpenTermOnSystemUserChooses
    {
     WINDOW_TYPE    PERM_TERMINAL
     EXEC_HOST      %(String)“Remote terminal on:”%
     TERM_OPTS      -title %(String)“Window title:”%
     EXEC_STRING    $SHELL
    }

### Specifying a Different Default Terminal Emulator

The default terminal emulator used by actions is `dtterm`. You can change this to another terminal emulator. The default terminal emulator is used when the action does not explicitly specify a terminal emulator to use.

The terminal emulator used by actions must have these command-line options:

- `-title` window_title

- `-e` command

Two resources determine the default terminal emulator used by actions:

- The `localTerminal` resource specifies the terminal emulator used by local applications.

      *localTerminal:    terminal

  For example:

  *localTerminal: xterm

- The `remoteTerminal` resource specifies the terminal emulator used by remote applications.

      *remoteTerminal:   host:terminal [,host:terminal…]

  For example:

      *remoteTerminal: sysibm1:/usr/bin/xterm,syshp2:/usr/bin/yterm

## Restricting Actions to Certain Arguments

Restricting an action to a particular type of argument refines the action. For example, it is useful to restrict an action that invokes a viewer for PostScript files to only PostScript file arguments; with the restriction, the action will return an error dialog if a non-PostScript file is specified.

You can restrict actions based on:

- The data type of the file argument.

- The number of file arguments—for example, no arguments versus one or more arguments. This provides different drop and double-click behavior for the action icon.

- The read/write mode of the argument.

### Restricting an Action to a Specified Data Type

Use the `ARG_TYPE` field to specify the data types for which the action is valid. Use the data attribute name.

You can enter a list of data types; separate the entries with commas.

For example, the following action definition assumes a Gif data type has been created.

    ACTION Open_Gif
    {
     TYPE           COMMAND
     LABEL          “Display Gif”
     WINDOW_TYPE    NO_STDIO
     ARG_TYPE       Gif
     ICON           xgif
     DESCRIPTION    Displays gif files
     EXEC_STRING    xgif
    }

### Restricting an Action Based on the Number of Arguments

Use the `ARG_COUNT` field to specify the number of arguments the action can accept. Valid values are:

`*` | (Default) Any number of arguments. Other values have precedence over `*`.
n | Any non-negative integer, including 0.
`>`n | More than n arguments.
`<`n | Fewer than n arguments.

One use for `ARG_COUNT` is to provide different action icon behavior, depending on whether the user double-clicks the icon or drops a file on it. See the next section, SAG.CrAct.div.47.

### To Provide Different Double-Click and Drop Behavior

Use this procedure to create an action that accepts a dropped file but does not prompt for a file when the action icon is double-clicked.

1. Create an action definition for the double-click functionality.

   Use the `ARG_COUNT` field to specify `0` arguments. Use a syntax for the `EXEC_STRING` that does not accept a dropped argument.

2. Create a second action definition for the drop functionality.

   Use the `ARG_COUNT` field to specify `>0` argument. Use a syntax for the `EXEC_STRING` that accepts a dropped file.

For example, suppose the following two command lines can be used to start an editor named `vedit`:

- To start the editor with no file argument:

      vedit

- To start the editor with a file argument that is opened as a read-only document:

      vedit -R filename

The following two actions create drop and double-click functionality for an action named Vedit. The first action has precedence when the database is searched for a match, since `ARG_COUNT` `0` is more specific than the implied `ARG_COUNT` `*` of the drop functionality definition.

    # Double-click functionality
    ACTION Vedit
    {
     TYPE         COMMAND
     ARG_COUNT    0
     WINDOW_TYPE  PERM_TERMINAL
     EXEC_STRING  vedit
    }

    # Drop functionality
    ACTION Vedit
    {
     TYPE          COMMAND
     WINDOW_TYPE   PERM_TERMINAL
     EXEC_STRING   vedit -R %Arg_1%
    }

### Restricting an Action Based on the Mode of the Argument

Use the `ARG_MODE` field to specify the read/write mode of the argument. Valid values are:

`*` | (Default) Any mode
`!w` | Non-writable
`w` | Writable

## Creating Actions that Run Applications on Remote Systems

When discussing actions and remote execution, there are two terms that are used frequently:

database host | The system containing the action definition
execution host | The system where the executable runs

In most situations, actions and their applications are located on the same system; since the default execution host for an action is the database host, no special syntax is required.

However, when the execution host is different from the database host, the action definition must specify where the execution string should be run.

The ability to locate actions and applications on different systems is part of the client/server architecture of the desktop. For a more in-depth discussion of networked applications, see SAG.ClSrv.mkr.15.

### Creating an Action that Runs a Remote Application

Use the `EXEC_HOST` field in the action definition to specify the location of the application.

Valid values for `EXEC_HOST` are:

`%DatabaseHost%` | The host where the action is defined.
`%LocalHost%` | The host where the action is invoked (the session server).
`%DisplayHost%` | The host running the X server (not allowed for X terminals).
`%SessionHost%` | The host where the controlling Login Manager is running.
hostname | The named host. Use this value for environments in which the action should always be invoked on one particular host.
`%“`prompt`”%` | Prompts the user for the host name each time the action is invoked.

The default value is `%DatabaseHost%`, `%LocalHost%`.
Thus, when the `EXEC_HOST` field is omitted, the action first attempts to run the command on the host containing the action definition. If this fails, the action attempts to run the command on the session server.

#### Examples

- This field specifies host `ddsyd`:

    EXEC_HOST  ddsyd

- The field prompts for a host name:

    EXEC_HOST  %“Host containing application:”%

- This field specifies that the action will attempt to run the application on the host containing the action definition. If this fails, the action will attempt to run the application on host `ddsyd`.

    EXEC_HOST  %DatabaseHost%, ddsyd

## 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

1. 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

1. 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

1. 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

### To Localize an Existing Action

1. Create a file in the appropriate language-dependent directory (for example, in `/etc/dt/appconfig/types/japanese`).

2. Copy the action definition to the language-dependent configuration file.

   For example, you might copy an action definition from

       app_root/dt/appconfig/types/C/file.dt

   to

       app_root/dt/appconfig/types/japanese/newfile.dt

3. Add a `LABEL` field or modify the existing `LABEL` field.

       LABEL   string

   Application Manager and File Manager use the label string to identify the action's icon.

4. Localize any of the following fields in the action definition:

   - For localized icons: `ICON`

   - For localized On Item help: `DESCRIPTION`

   - For localized prompts: any quoted text in the `EXEC_STRING`

## Creating Actions for ToolTalk Applications

The following information applies only to applications that support ToolTalk messaging.

Use the action type `TT_MSG` to create an action that sends a ToolTalk message.

    ACTION action_name
    {
     TYPE  TT_MSG
     …
    }

### addressing and disposition Fields

- The ToolTalk `addressing` field is always set to `TT_PROCEDURE`.

- The ToolTalk `disposition` field defaults to the specification in the static message pattern.

#### Unsupported Messages

The following are not supported by `TT_MSG`-type actions:

- ToolTalk object-oriented messages

- Context arguments in messages

#### Keywords for TT_MSG Actions

Keyword | Use
`TT_CLASS` | Defines the value of the ToolTalk `class` message field
`TT_SCOPE` | Defines the value of the ToolTalk `scope` message field
`TT_OPERATION` | Defines the value of the ToolTalk `operation` message field.
`TT_FILE` | Defines the value of the ToolTalk `file` message field
`TT_ARGn_MODE` | Defines the value of the ToolTalk `mode` attribute for the nth message argument
`TT_ARGn_VTYPE` | Defines the value of the ToolTalk `vtype` attribute of the nth message argument
`TT_ARGn_VALUE` | Defines the value of the nth message argument