Summary: passing variables to rlogin

[umh at vax5.cit.cornell.edu]

A few days ago I posted a question essentially asking how I could pass
variables to rlogin, within the context of being able to
rlogin to a remote machine and have my DISPLAY variable automatically follow
me. A number of people replied to me about this. Many
thanks to those who helped me. There were also many extremely rude replies
telling me to look at the X Frequently Answered Questions
or to read the manual, all of whose authors completetly missed my point.

The issue I was trying to address was NOT Rhow do I create an xterm logged into
another machine but displaying on my machine?S, or
Rhow do I use rsh to run an X program on a remote machine and have itUs display
automatically sent to the machine IUm sitting at?S
My question was very much withing the context of rlogin- what I wanted was to
able to, from an extant xterm window, rlogin to
another machine, perform various work there- editing, compiling, etc, and
ocasionally test my X binary by running it on the remote
machine and having its display automatically routed to the machine from which I
rlogged in. I do NOT want extra xterm windows
popping up in this process. If you *do* want new windows appearing when yo
login to different machines, then the xrsh script in the
X FAQ is probably of more use to you than what I have to say.

The answer to what I want to do, suggested by two people, is to utilize the
fact that the term variable is sent to the remote rlogin
process, hence one encodes whatever information one wishes to use in the term
variable and parses term in oneUs .login script. This
works very well, the one gotcha being that the .login on EVERY machine you
rlogin to must have this parsing put into it, otherwise
it will complain about the term variable it is being sent.

So the idea is to put in oneUs .login something like below: 

if ( $TERM == "dialup" || $TERM == "sytek" ) then
        # setup vt100 characteristics for dialup
        set term = vt100
else if ( $term =~ *@* ) then
        #setup DISPLAY variable
        setenv DISPLAY `echo $term | sed 's/.*@//' | sed 's/:.*//'`:0
        set term = `echo $term | sed 's/@.*//'`
else
        #unencoded term variable sent.
        set term = $TERM
endif

I donUt know what the difference between term and TERM at rlogin time is, so
some of these operations may be redundant, but the
above does work for both network and dialup access on our machines.

To encode term, one uses a script which I call r, something like below:

#!/bin/csh -f
if ( $#argv != 1) then
        echo usage: r hostname
        exit (1)
endif

xhost + >& /dev/null
if ( $DISPLAY == unix:0.0 ) then
        set term = ${TERM}@`hostname`
else
        set term = ${TERM}@${DISPLAY}
endif
rlogin $1


This is not completely general- eg it does not handle the -l option of rlogin,
but I never use that so I couldnUt be bothered to
include it. Changing the above to be more general is obviously easy- replace
the $1 with $* and throw out the error check (or devote
lots of energy to getting it right.)

There are other possible solutions. Some people proposed kludges with files,
relying on NFS to have these seen by the remote
machine. I was using something like that, but it becomes very ugly when you
often login from one NFS network to another. Also that
scheme dies when you login from a, then to b, the from b to c, or if you login
to the consoles of two machines simultaneously.

Other people pointed out that when one runs who, one of the fields is the
network address of oneUs login connection, so that in
.login, one can run who, scan for oneUs name, and parse this connection field
with sed. This suffers from the fact that the
connection field is truncated at 15 characters, so one has to put some smarts
in the script to extrapolate beyond there, or to
truncate at a sensible place, but may be useful under some circumstances.

I was told that on Suns there is a program called last which provides a history
of oneUs logins, and so could be utilized in the
place of the above with who, and which would probably be more elegant.

Hope this helps.

Maynard Handley