This page describes a technique for starting
an application program in HDSterm automatically.
Auto-Starting
an Application in HDSterm
Many ViewStation users would like to
customize their environment and make their operations more productive
by having an automatic start for their applications in a terminal
window. This is possible with the MIT Xterm client, and many
ViewStation users would like the same capability in their HDSterm
windows.
Xterm Operation
Automatic starting of clients is possible using Xterm and is
typically used with a window manager "root menu" to enable the user to
kick-off customized Xterms running specific applications.
For instance, a user might want to start the Uniplex
application in an Xterm window from the window manager menu. With Xterm,
a user would add a line to their .mwmrc RootMenu such as:
"Uniplex" f.exec "xterm -e uniplex"
When the user clicks on this menu item, a new Xterm window opens and
automatically starts a Uniplex process in the window. When the user
quits Uniplex, the Xterm automatically quits too.
HDSterm Operation
The principal difference
between Xterm and HDSterm is that one is run on the host computer
(Xterm) and the other is run on the local display (HDSterm on the
ViewStation). The advantages of this local operation are significant,
but it does present a limitation in using an autostart operation.
While HDSterm supports the "execute" (-e) command argument to
autostart another program to run in the HDSterm's window, it has the
same limitation that Xterm has: The autostart program must be a process
running on the "local" machine, that is, the machine running the
HDSterm or Xterm client. In the case of Xterm, this can be any process
running on the host computer. In the case of HDSterm, it can only be a
process running on the ViewStation.
This limitation of running clients only on the local machine
applies both to Xterm and HDSterm. For instance, if you wanted to run
Xterm on host 1 and execute a client on host 2, the autostart command
would fail. You might think that you could get around this limitation
of Xterm by typing:
xterm -e rsh <anotherhost> uniplex
but this
process would fail too.
Daemon Operations
The problem with this attempt is that the remote shell process
(rsh) connects to a remote shell daemon (rshd) on the remote host,
which in turn launches the Uniplex program. But the rsh daemon, unlike
the rlogin daemon or the telnet daemon (other processes to do this
operation), does not create a pseudo-tty for communication with the
Uniplex application. Most character-based applications that run in a
terminal emulation window, including Uniplex, vi, etc., do not operate
properly if their input and output is to a network socket rather than
to a tty connection.
Unfortunately, neither the rlogin daemon nor the telnet daemon
have provision in their operation protocol to launch another task once
they set up the pseudo-tty communication. Both of these daemons execute
the "/bin/login" process, which records the login system files and then
starts up the user's default shell.
An HDSterm solution
A simple solution exists which makes use of HDSterm's customizable
"answerback" message. The general idea is to request the answerback
message from HDSterm as part of your startup shell script, and then to
enter your application program command line as the content of the
answerback message. In this way, the application program is started by
your startup shell script.
Additional customization, described below, allows you to use
this facility from your window manager's menu, and lets you have
several applications available to you with this feature. Follow these
steps:
Step 1: Add the following entry at end of your default
shell startup script (.cshrc or .profile in your home directory):
echo "^E"
This "^E" (Control-E) is the standard ENQ or "Enquiry"
ASCII control code. Most VTxxx terminals, including HDSterm, respond to
this control code by sending a user-specified answerback message (note
that currently the standard MIT Xterm ignores the ENQ code). The
answerback message is used infrequently and the default setting for
most VTxxx terminals is an empty answerback string.
By putting the echo command at the end of the user's startup
script, the echo is executed just as the login shell is ready to accept
user input. If the answerback message consists of one or more shell
commands followed by a newline, the answerback message will provide the
commands to be executed by the shell.
Step 2. Make the command line for the answerback message:
If you wanted to start the Uniplex application from HDSterm,
use this command line: setenv TERM vt100; uniplex; exit\n
Since HDSterm's answerback message is specified by an X
resource, it is possible to customize the message for any given
instance of the HDSterm client. For example, the answerback message
shown above does three things.
1. It sets the TERM environment variable for the window. Note that
the rlogin daemon automatically sets the TERM environment variable to
the "vt220", since HDSterm specifies this to rlogind. For various
reasons, you may wish to override the TERM variable with a different
terminal type for the process group running this specific application.
2. It starts Uniplex
3. It sets the "exit" command, which causes the window to close
when you leave Uniplex. Test the command line for correct operation
before you use it.
Step 3. Modify the HDSterm resource to set the new
answerback message:
HDSterm's resource which sets the answerback message also includes
a number of other items which must remain exactly as in the HDSTerm
app-defaults file. You can find this file by opening a Console window
and entering these commands: HDS> cd HDS$$ROM
HDS>
more HDSTerm
This is part of the HDSTerm app-defaults file (the
relevant section is at the end of the file). The following entry is
the resource as given in the HDSTerm app-defaults file:
*term.vt220-rops: \
1 <%gA%c> \
2 <\\E[%gy%d;%gx%dS> \
3 <\\E[%{gy,1,+,d};%{gx,1,+,d}R> \
6 <%"Welcome to HDSterm"%s>
\
7 <\\E[0n> \
8 <\\E[?62;1;2;6;7;8;9c> \
9 <\\E[%{gx,2,+,d};1;1;112;112;1;0;x> \
100 <%{ \
77 C 75 C 0 pP \
"ascii" p0 "dec" p1
"graphics" p2 "uk" p3 \
0 p5, 1 p6 \
"ascii" pa 32 pb 33 C \
"dec" pa 160 pb
33 C \
0 pF \
0 gT = ? "composeKeys" pa 32 C \
1 pK 1
pC 1 pX 1 pT ; \
1 gK = ? "numKeypad" pa 32 C 0 pK ; \
1 gC
= ? "normCKeys" pa 32 C 0 pC ; \
1 gX = ? "fkeys" pa 32 C \
"miscFkeys"
pa 32 C 0 pX ; \
34 C gy 1 - pa 0 pb 21 C \
53 C 0 px 0 py 1
C \
0 pa 60 C \
0 pb 61 C \
}>
The line which specifies the answerback message is the
fifth line: 6 <%"Welcome to HDSterm"%s> \
The procedure to customize the message for specific
instances of HDSterm is as follows:
1. Choose a unique name for each instance of HDSterm, one for each
different application which you want to autostart. For example, you
could use "Uniplex" for an HDSterm which runs Uniplex, and "Mail" for
an HDSterm which runs /usr/ucb/mail, your mail application, etc.
2. Create a separate resource file entry which contains a
"vt220-rops" resource for each different instance, using the chosen
names as the "application name". You can do this either by copying this
part of the app-defaults file, or by using cut-and-paste from the
Console window into your .Xdefaults file. You must use this whole
segment of the file.
Customize the answerback string in each resource with the
necessary command line to launch the desired application. Follow these
examples:
Uniplex*term.vt220-rops: \
1 <%gA%c> \
2 <\\E[%gy%d;%gx%dS> \
3 <\\E[%{gy,1,+,d};%{gx,1,+,d}R> \
6 <%"setenv TERM vt100;
/usr/bin/uniplex; exit\\n"%s> \
7 <\\E[0n> \
8 <\\E[?62;1;2;6;7;8;9c> \
and so on ....
Mail*term.vt220-rops: \
1 <%gA%c> \
2 <\\E[%gy%d;%gx%dS> \
3 <\\E[%{gy,1,+,d};%{gx,1,+,d}R> \
6 <%"/usr/ucb/mail; exit\\n"%s> \
7 <\\E[0n> \ 8
<\\E[?62;1;2;6;7;8;9c> \
and so on ....
Note that you must use the entire "vt220-rops:" entry - these
are just file fragments.
The syntax for the answerback line is
a "6", followed by a space, followed by "<%", followed by the desired
string in double quotes, followed by "%s>", a space, and a backslash.
There may not be any spaces or other characters following the
backslash. In order for the user's shell to execute the answerback
string as a command, it must end with a newline. This is specified by
adding \\n just before the terminating double quote (two backslashes
before the "n").
3. Put these resources in your .Xdefaults file in your home
directory. Preload the .Xdefaults resource file shown above into the
ViewStation's RESOURCE_MANAGER property by running xrdb, the X Resource Manager. This may be done as part of an Xdm .xsession
startup script. Loading these resources into the X Server's
RESOURCE_MANAGER property allows them to override HDSterm's
app-defaults, without requiring HDSterm to load a remote resource file
every time it starts.
Step 4. Add the commands to open the HDSterm window to
your client launcher.
For example, you could auto-start
Uniplex by adding the following line to your window manager menu (such
as .mwmrc) , or to your .xsession file (if you're using Xdm), or some
other client launcher file:
For an .mwmrc menu entry:
"Uniplex Window" f.exec "hdsterm -name Uniplex -e rlogin
myhost"
"Mail Window" f.exec "hdsterm -name Mail -e rlogin myhost"
For an .xsession file:
rsh <ViewStation name> "hdsterm -name Uniplex -e rlogin
<hostname> &"
These command lines do a remote login to the host
specified and execute the user's startup shell script (which contains
the "echo "^E" line at the end).
The "name" argument finds the appropriately renamed *term
resource and uses the answerback message defined in the resource entry.
Note that this requires that HDSterm was started remotely, or
from a Remotely Started Window Manager, and
that the /etc/hosts.equiv and/or $HOME/.rhosts files are set up
properly. These are prerequisites to correct operation of the remote
shell command. It also requires that the user be logged in (username
and password) before the command is sent.
If this is correctly configured and run, the rlogin request to
the <remote host> will pass the user's name and password, and will
then immediately execute the user's startup shell script. The shell
script in turn sends the ENQ code to HDSterm, which then sends the
answerback string (your command line) to be executed in the new shell.
If you will be logging in from something other than HDSterm,
Xterm, or a VTxxx terminal, you may wish to execute the echo command
conditionally based on the appropriate TERM environment variable.
Return to Section Heading Page
Return to the Home Page
If you need more information than is available here, you can reach
HDS via email at info@hds.com, or
call us at 1.800.HDS.1551 in the USA, or at +610.277.8300 from outside
the US. For questions or problems regarding the HDS WWW page, contact
webmaster@hds.com.
© 1996 by HDS Network Systems
Inc.