rlogin with adoption of $DISPLAY

rlogin wont accept to export DISPLAY variable, but you can
do this workaround

 Place the line "export DISPLAY=xxxxx" in the .profile of
the remote user that you want to rlogin.

telnet will correctly propogate the DISPLAY environment variable, rlogin won't.

If typing in your password is too painful, you can still use rlogin, if you go to some extra trouble to get the DISPLAY parameter across.  On the remote side, you could have it default to a particular DISPLAY, if, for instance, you usually run your Exceed on the same windows box.  Or you could use 'expect' to transfer the data over for you (see http://www.uni-ulm.de/urz/Hard_Software/Dokumentationen/free_unix/expect/xrlogin).  Or a myriad of other hacks...

> telnet will correctly propogate the DISPLAY environment variable, rlogin won't.

NO, or may be.
This behaves on the version of telnet, rlogin and the deamon accepting the connection on the remote host. For example on IRIX the environment variable REMOTEHOST is passed through and evaluated by the deamon.

There is no simple way to set $DISPLAY to the right value, especially when you're doing nested (r)logins.

If the host where you issue the rlogin/telnet command is also your display host (where the X-Server is running), you may compute the DISPLAY variable using the
    who am i
or
    tty
or
    w
command, or a combination of them.
But keep in mind that this is hard stuff, 'cause it depends on:
  - the shell you start rlogin ($SHELL)
  - the OS you start rlogin (uname -s)
  - sometimes the terminal where you start rlogin ($TERM)
  - the shell for the remote account
  - the OS on the remote host

A quick&dirty solution for most people is to wright the setting of the DISPLAY variable hardcoded in ~/.profile, ~/.login or adequate files, probably inside a switch detecting the host or os..

>  setenv DISPLAY `who am i | awk '{print $6}' | tr -d "()"`:0.0

be careful using this (see my last comment), it does definitely not work on HP-UX, where you need to use
   who am i -R
AFAIK, on IRIX it also fails.

Offtopic:

It is highly suggested to avoid using rlogin and telnet
due to it's security weakness.

Wherever possible use SSH.

By the way, SSH provides SAFE X11 forwarding ...

Paul.

Don't know of anyway to do that (Don't think u can)I agree with other comments, edit your .profile with the DISPLAY=

I tried the command of yuzh. This works when i change the user with "su". So that's fine. But with rlogin the "who"-command only tells the name of the hostname and not the terminal (=Display) -Name.
I don't to code the DISPLAY=... line in .profile, because I'm not the only one who is working with the same Unix-Login in the project.
Nevertheless
thanks for the comments
olka

Hi  olka,

    If you have tcsh install on your system,  you can get arround with
this problem.

   You can write a little script lets called it-- ckremote:

#!/bin/tcsh -f
#
      if ( $?REMOTEHOST ) then
           setenv MACHINE `echo ${REMOTEHOST} | cut -d. -f1`
           echo "${MACHINE}:0.0" > ~/.dsplay
      else
           setenv MACHINE `hostname`
           echo "${MACHINE}:0.0" > ~/.dsplay
      endif

#

if you are a sh/ksh/bash user, you can put the following in the .profile
#
# Auto set the DISPLAY for X server
#
    /home/yuzh/bin/ckremote
    DISPLAY=`cat ~/.dsplay`
    export DISPLAY

#========================================================

if you are runing tcsh/csh then put, the following in you .cshrc file
#
# Set the X server to the host where we logged in on
#
      if ( $?REMOTEHOST ) then
           setenv DISPLAY ${REMOTEHOST}:0.0
      else
           setenv DISPLAY :0.0
      endif

#========================================================

   That's what I did for the users in my systems, we are runing Solaris,

and it works fine, it also work for the X term on PC.

   Just give it a try.

   Good Luck!

Regards
   yuzh

yuzh, again this does not work for nested (r)logins.
Best is to use ssh, which forwards the DISPLAY setting, in nested ssh also.

I'll add a "Me Too!" for the ssh suggestions.  I've fought with this for as long as I can remember, and ssh just makes it all go away.  Add to that the extra security you buy with encrypted network traffic, and there's really no reason not to use it.  Most competent Admins know about, and have already installed, ssh.  

Try www.openssh.org for unix clients (and servers).
I've found that puTTY is an excellent ssh client for Windows boxes.  The "released" version doesn't support X11 tunneling, but the beta version does.    Get it from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Good Luck

.. and if you don't need ssh protocol version 2.0, you might use TeraTerm which forwards X (and any other port too). It also mimics the X11 behaviour for copy&paste, and I never have seen it crashing ...
For example from
http://www.zip.com.au/~roca/ttssh.html
http://hp.vector.co.jp/authors/VA002416/teraterm.html