Smart Card Shell

Shell Configuration

All configuration of the shell is done from within the scripting environment. The top level scripting object is instantiated when the shell is started. This so called global object contains all global variables and function definitions. When executing scripts, then these run in the context of the global object.

During startup, the Smart Card Shell will try to find and execute the CONFIG.JS file, unless the user specifies an alternative script for configuration. The CONFIG.JS file provides for the basic shell configuration. It defines the required scripting classes, global definitions and shortcut functions. After the CONFIG.JS script is completed, the shell is ready configured.

In the default CONFIG.JS file, a global object under the name "_scsh3" is created. This object contains persistent configuration informations that can be changed from within the scripting environment.

Card Terminal Configuration

The Smart Card Shell uses the OpenCard Framework (OCF) to access card terminals and smart cards. OCF has it's own configuration mechanism using a property file named opencard.properties.

When OCF is started by the Smart Card Shell, then OCF looks for configuration information in three different locations:

[java.home] is the directory where the Java runtime is installed. The configuration file there may be used for system and application wide configurations.

[user.home] is the user's home directory on the system. For Windows this is the "Document and Settings"/"User Name" directory.

[user.dir] is the current directory when the application is started.

OCF will read configuration information in the order defined above. The Smart Card Shell installation places a default opencard.properties file in the directory where the executable is installed. This default configuration enables all PC/SC card terminals and configures the necessary card service factories.

A user specific configuration can be added by creating a file named .opencard.properties in the home directory of the user.

Adding CT-API Card Terminals

The Smart Card Shell comes bundled with the CardContact JNI2CTAPI and CTAPI4OCF drivers. These allow to access CT-API card terminals from OCF. JNI2CTAPI is a Java Native Interface to the CT-API dll or shared object provided by the card terminal manufacturer. CTAPI4OCF implements an OCF card terminal driver that maps OCF methods to CT-BCS card terminal commands.

A CT-API card terminal is added using the

    de.cardcontact.opencard.terminal.ctapi4ocf.CTAPICardTerminalFactory

card terminal factory. This factory can be configured with four parameter separated by a '|'

    |name|type|device|libname

The parameter name is a user selected friendly name for the card terminal. The parameter type must contain 'CTAPI'. The port number to be used in CT_INIT() is defined by the device field.

The name of the DLL or shared object is defined in the libname field. The name of the DLL or shared object must be given without extension or leading 'lib'.

The following example shows the configuration for 3 different CT-API card terminals:

# ORGA ECO 5000 with CardContact ECO5000 driver
OpenCard.terminals = \
 de.cardcontact.opencard.terminal.ctapi4ocf.CTAPICardTerminalFactory|ECO5000|CTAPI|1|cteco5000

# ORGA MCT 5000
OpenCard.terminals = \
 de.cardcontact.opencard.terminal.ctapi4ocf.CTAPICardTerminalFactory|MCT|CTAPI|1|ctorg32

# Reiner SCT CT-API Driver
OpenCard.terminals = \
 de.cardcontact.opencard.terminal.ctapi4ocf.CTAPICardTerminalFactory|REINERSCT|CTAPI|1|ctrsct32

# G+D ICT800 STD
OpenCard.terminals = \
 de.cardcontact.opencard.terminal.ctapi4ocf.CTAPICardTerminalFactory|ICT800|CTAPI|1|ctapiw32

If more than one CT-API card reader shall be added, then the factory and configuration must be given multiple times on the same line, separated by blanks. Entries can span multiple lines, if they end with a backslash as shown above.