DISPLAY environment variable from login(1)

[Barton E. Schaefer]

In article <2273 at marvin.Solbourne.COM> dce at Solbourne.com (David Elliott) writes:
} In article <4045 at buengc.BU.EDU> bph at buengc.bu.edu (Blair P. Houghton) writes:
} >Only, login(1) creates an entirely new set of environment variables,
} >effectively ignoring the imported environment, and DISPLAY in particular.
} 
} Yep, this is a real pain.  I've seen a lot of solutions, but most
} end up asking the user or assuming no more than one rlogin.

Most rlogins (except those on certain unusually brain-damaged Xenix and SysV
implementations) pass the value of $TERM to the remote login process, so
that the terminal type can be set correctly without asking the user.

So, you create a front-end script on the local machine that looks like

    #! /bin/sh -
    TERM="$TERM.$DISPLAY" ; export TERM
    exec /path/to/real/rlogin ${@+"$@"}

and then in .login on the remote machine you do

    # While $term has a .suffix
    while ("$term" != "$term:r")
	# If $display already contains something
	if ($?display)
	    # Append the .suffix to $display
	    set display="$display.$term:e"
	else
	    # Initialize $display as the suffix
	    set display="$term:e"
	endif
	# Strip off one suffix from $term
	set term="$term:r"
    end
    # If we built a $display, export it
    if ($?display) setenv DISPLAY "$display"

You Bourne shell people can probably figure out how to do the same thing
with "basename" and/or "sed".

If the value of $DISPLAY is particularly long, this may run into problems
with the lenght of the string that rlogin will pass as $TERM.  However,
I've used this trick to pass other information across rlogins with no
toruble whatsoever.
-- 
Bart Schaefer           "And if you believe that, you'll believe anything."
                                                            -- DangerMouse
CSNET / Internet                schaefer at cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer