scoadmin -- SCOadmin hierarchy contents and format


Each management application in the SCOadmin launcher has a corresponding object in the SCOadmin object hierarchy. To add a management application to the SCOadmin desktop, you must create a management object to be added to the hierarchy in the appropriate place. The required contents are as follows:
          |                 |
   activate.scoadmin      en_US


Each management application listed in the SCOadmin launcher has a corresponding object directory in this hierarchy. When a new management application is to be added to the SCOadmin launcher, an object directory is added for it in the hierarchy. These object directories have names which end with the extension .obj. The intention is that management objects should be placed into this hierarchy in a logical grouping. Folders in the hierarchy represent a grouping of applications.

SCOadmin applications and hierarchies must be configured and maintained using the scoadmin(1M) command.

The SCOadmin management object hierarchy is located in:


At installation, the SCOadmin object hierarchy is preconfigured into an initial state. This preconfiguration includes the following standard folders (application categories):


The activate.scoadmin file

The activate.scoadmin file permits the object to be invoked from scoadmin(1M). This file must be a valid executable type (such as a binary, shell or tcl script). scoadmin simply invokes the file assuming it is an executable. If activate.scoadmin is a script, then the #! mechanism must be used to invoke the appropriate interpreter. The suggested permissions are 0555.

If this file is not found when a user attempts to invoke the application from scoadmin, a message is displayed that the application cannot be invoked.

Two environment variables are set by scoadmin in the environment of activate.scoadmin:

informs the activate.scoadmin executable of the display environment. The possible values are MOTIF and CHARM. This can be used to prevent a graphical-only application from being executed in the character environment. Example uses of this variable are found in ..

contains the name of the management object selected, mimicking the variable of the same name set by X.desktop when a user double-clicks on an object. It includes the full path name of the .obj directory for the corresponding management application. It is convenient to use this variable when referring to files within the management object.

The language directory

Language directories are used within objects to store language specific data for the purpose of internationalization. The current directories are: ja_JP, ja_JP.SJIS, fr_FR, de_DE, and en_US. The launcher maps the value of the LANG environment variable to one of these values. If LANG is not set or if its value does not map to one of the recognized values, the default is en_US. This directory should be provided with every management object.

The following subsections describe the data which may reside in the language directories.

The title file

This file should contain the title of the application in the corresponding language. The title file can contain a multi-line title. scoadmin uses the title in presenting the user with a list of the available applications. A file named title should reside in each of the language directories of a management object.

If the desktop cannot find a language directory matching the current language setting or an en_US language directory, it uses the name of the management object directory as the title of the application. The same applies if the desktop finds the appropriate language directory, but does not find a title file in it. In either of those cases, if the management object directory was named Printer Setup Manager.obj then it will use Printer Setup Manager as the title. It is recommended that management object directories have meaningful names. In the example given here, a space character is used in the name of the directory such that the title appears more legible.

A character/motif application

This example application is capable of running in both the character and MOTIF environments. SCO Visual Tcl applications are an example of this type of application. The following is a simple executable script:
   #! /bin/sh


Note that the first line invokes the shell. This file could have also been a csh(1), ksh(1), or SCO Visual Tcl executable, including a binary executable.

A character only application

In this example, the application is capable of running in a character environment only:
   #! /bin/sh

if [ "$SCOADMIN_UIMODE" = CHARM ] then mkdev hd else scoterm -title "mkdev hd" -e sh -c "mkdev hd" fi

Note the use of the SCOADMIN_UIMODE environment variable. When scoadmin executes this script, it sets SCOADMIN_UIMODE to either MOTIF or CHARM according to the display environment. It is then up to the character-only management object to ensure that the management application is invoked correctly. In this example, if the MOTIF environment is detected, the application is run in a scoterm.

A motif only application

This example uses scomail as an application which can only run in a MOTIF environment. Here the SCOADMIN_UIMODE environment variable is used to identify the display environment. In a character environment, the application cannot be invoked and scoadmin is used to display a message to that effect:
   #! /bin/sh

if [ "$SCOADMIN_UIMODE" = CHARM ] then scoadmin -m "This application must be run in a MOTIF environment." else /usr/bin/X11/scomail fi


SCOadmin desktop activation file

application title


© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 25 April 2004