cue(1)

Series 800 Only

NAME

cue − HP Character-Terminal User Environment (CUE)

SYNOPSIS

/bin/cue

DESCRIPTION

CUE provides an easy-to-use, attractive, customizable environment that allows users on Series 800 HP-UX systems to easily identify themselves to the system and begin a work session. CUE supports the following terminals:

HP700/92HP700/94HP2392HP2394

A menubar is available for changing the native language of the session, changing the type of session to start upon a successful login, or getting on-line help. To obtain context-sensitive help at any time, press the function key labeled HELP (f1).

A pulldown menu and function keys (f1-f8) are displayed, allowing the user to modify various options or to get help. Before the login is initiated, the user has the option of interactively changing the native language of the session and the type of session to start upon a successful login.

The default native language is C, but the language is easily modifiable by entering the Language Menu which is accessible by selecting the Configuration item in the menu bar. The native language can also be specified as a parameter to cuegetty (see cuegetty(1M)).

The default session type is the Bourne shell, sh, but the session type can be easily changed to tsm, keysh, ksh, or csh by entering the Session Type Menu which is accessible by selecting the Configuration item in the menu bar.

The following standard login features are available:

• password aging

• logging invalid login attempts in /etc/btmp

• list of valid ttys for super-user login

CUE displays a visual screen that prompts for the username and password. CUE asks for the username and the corresponding password. If your username doesn’t have a password, just press the <carriage return> key to skip this field. Terminal echo is turned off (where possible) during typing of the password so that it will not appear on any written record of the session. After three unsuccessful login attempts, a hangup signal is issued.

If password aging has been invoked by the super-user on your behalf, your password may have expired. In this case, you will be diverted into passwd(1) to change it, after which you can attempt to login again.

If login is not successfully completed within a certain period of time (e.g., five minutes), the terminal may be silently disconnected.

After a successful login, the accounting files are updated, user and group id’s, group access list, and working directory are initialized. If the session type chosen is tsm, the SHELL to start in each tsm session is determined from corresponding user entries in the /etc/passwd file. CUE then forks the appropriate shell by using the last component of the shell pathname preceded by a − (for example, −sh or −ksh). When the session type is invoked with its name preceded by a minus in this manner, the shell performs its own initialization, including execution of profile, login, or other initialization scripts.

For example, if the user login shell is sh(1) or ksh(1) the shell executes the profile files /etc/profile and $HOME/.profile if they exist (and possibly others as well, depending on what they contain). Depending on what these profile files contain, messages regarding mail in your mail file or any messages you may have received since your last login may be displayed. At this point, cuesession is started to perform some accounting, display messages, and start your session.

If /etc/btmp is present, all unsuccessful login attempts are logged to this file. This feature is disabled if the file is not present. A summary of bad login attempts can be viewed by users with appropriate privileges by using lastb, see last(1M).

If /etc/securetty is present, login security is in effect, meaning that only users with appropriate privileges are allowed to log in successfully on the ttys listed in this file. Restricted ttys are listed by device name, one per line. Valid tty names are dependent on installation. Some examples could be console, tty01, ttya1, etc. Note that this feature does not inhibit a normal user from using su.

INTERNATIONALIZATION

All screens, labels, and messages are localizable. The message catalog cue.cat contains the localized representations of the default labels and messages. Cue will read the appropriate message catalog indicated by the LANG environment variable and display the localized strings. By selecting a native language in the Language Menu, the language of the CUE screens and the future work session can be specified. If the the message catalog exists for CUE in the language selected, CUE will be redisplayed in that language. If not, the CUE screens will continue in the current language and the work session that is started after a successful login will be started in the language selected. In either case, the LANG environment variable will be set appropriately for the resulting work session.

If CUE will be started on the command line or as the last item in the .login file, the CUE screens will be brought up using the language specified by the LANG environment variable. If CUE screens do not exist for the language specified by LANG, then the the default native language, C, will be used.

If CUE will be started by cuegetty, it is possible to start up the CUE Login Screens in a language other than the default, C, by invoking cuegetty with the −L nls_language option. Of course, CUE screens and the cue.cat file must exist for the nls_language specified.

STARTING CUE

There are several methods that can be used to start cue.

• cuegetty(1M) entry can be placed in the /etc/inittab file. This is the preferred method as the user does not need to do anything further to start cue.

• cue(1) can be started on the command line by merely typing: cue. Or, it can be started as the last line in the user’s login configuration file.

Multiple cue logins may run simultaneously on separate terminals attached to the same local host. Cuegetty(1M) can be configured in the /etc/inittab file for all users.

Remote users to the CUE system must access CUE by entering the cue(1) command at the command line prompt or as the last item in the user’s login configuration file.

FILES

/etc/btmp history of bad login attempts

/etc/logingroup group file − defines group access lists

/etc/motd message-of-the-day

/etc/passwd password file − defines users, passwords, and primary groups

/etc/profile system profile (initialization for all users)

/etc/securetty list of valid ttys for root login

/etc/utmp users currently logged in

/etc/wtmp history of logins, logouts, and date changes

/usr/mail/your-name mailbox for user your-name

/bin/cue cue executable

/bin/cuegetty cuegetty executable

/bin/cue.etc/cue.inittab template for /etc/inittab

/bin/cue.etc/cue.dm screen descriptions

/bin/cue.etc/cuesession starts selected session type

/usr/lib/nls/$LANG/cue.cat NLS message catalog

/usr/man/man1/cue.1 man page for cue(1)

/usr/man/man1/cuegetty.1M man page for cuegetty(1M)

ENVIRONMENT

Cue will invoke the user’s session with the following default environment:

CUESESSION is set to the session type selected
valid values are :
/bin/sh         - Bourne Shell (DEFAULT)
/usr/bin/tsm    - manages up to 10 sessions at once
/usr/bin/keysh - Easy Context-Sensitive Softkey Shell
/bin/ksh        - Korn Shell
/bin/csh        - C Shell
HOMEis set to the home directory of the user
LANGis set to the native language selected (C is the default)
LOGNAMEis set to the user name
MAILis set to /usr/mail/$LOGNAME
NLSPATHis set to the path applications search for NLS message catalogs
usually /usr/lib/nls/%L/%N.cat
PATHis set to the path to be searched for commands -
:/bin:/usr/bin
SHELLis set to the user’s default shell (from /etc/passwd)

Several methods are available to modify or add to this list depending on the desired scope of the resulting environment variable.

Basic environment variables can be set for all CUE users on a system by setting the values in /etc/profile and /etc/csh.login. Personal environment variables can be set on a per-user basis in the script file $HOME/.profile for sh and ksh users or .cshrc for csh users.

Warning. Alias and function definitions need to be included in the file specified by ENV for ksh as this file will be sourced for each invocation of the shell. For csh users, the .cshrc file should be structured such that it cannot generate any output on standard output or standard error, including occasions when it is invoked without an affiliated terminal. rcp(1) causes .cshrc to be sourced, and any output generated by this file, even to standard error causes problems. Commands such as stty(1) should be placed in .login, not in .cshrc, so that their output cannot affect rcp(1).

For users with appropriate privileges, PATH is augmented to include /etc.

Museum

Related Articles