SUMMARY: Looking for set DISPLAY program

From: Michael D. Reynolds (
Date: Sat Jul 09 1994 - 03:25:30 CDT

X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 189

My origial question was...

> Hi sun managers,
> I'm looking for a piece of code to reliably sets the $DISPLAY variable
> upon login. I would much prefer shell script (so I don't have to compile
> for multiple architectures) but will use c code if necessary.
> I have written one (like many others) that cuts the system name or IP address
> out of the parenthesis in the "who" output and appends a ":0.0" to it.
> The problem with it is that there is a 16 char limit on that field in
> the who output. So it works great if the system is locally known (host table)
> or not known at all (IP Address), but if the system is known via DNS then
> the DNS name is likely to be > 16 chars and gets truncated. This field is
> part of the utmp structure which has the 16 char limit. I'm guessing that
> the login.c program fills the utmp structure and thus contains the magic system
> call to get the hostname, IP Addr, or DNS name of the system you came from,
> but I don't have source for it.
> Q1: Does anyone have a utility that returns...
> hostname (if system is in local/NIS hosts)
> IP Address (if system is unknown)
> DNS name (if system is known via DNS) untruncated
> of the system you came from.
> Q2: Can this be done in shell.
> If you can help please advise.

garrett@athena.SDSU.Edu wrote
> Check out the "xrsh" and "xrlogin" programs. These programs make *much*
> more sense to use, they run on the local client (and should be built into
> in any reasonable X terminal).

This sounds really great and I will try it for my local domain but I need
something that works with logins from all sources not just UNIX. wrote
> Here's Patrick Nolan's Perl script displayhost(1) that does what you
> want. It's based on Donald McLachlan's Bourne shell script of the same
> name, which is also included below. (attachement included)
> They're both plug and play.
> Enjoy,
> Eric De Mund <>

Then Patrick Nolan himself sent me "THE" newest copy of his perl script
(included below). (David B. Brown)
sent me a line of code that cuts the lowest level out of the DNS name in
the who output. This will only work if all the nodenames are at the same
level in the DNS namespace which is not the case here. Here it is for those
that can use it...

> set DISPLAYNAME = `who am i | awk '{print $6}'|sed 's/(//'|sed 's/)//'|sed 's/\..*//'`
> setenv DISPLAY $DISPLAYNAME":0.0" (Olav Lerbrekk) wrote
> Try RXX by Duncan Sinclair <>. It will export the
> the remote host is off-site, in which case only DISPLAY is exported.
> Works great!
> Olav

Sounds alot like xrsh above.

David Lawrence Oppenheimer <davido@phoenix.Princeton.EDU> wrote
> You might try the 'host' command... Try an archie search to find it; it
> might help.
> If you can somehow get the IP address of the host that's calling, then
> you can of course setenv DISPLAY ${HOST}:0.0 ...

Some combination of 'host' and 'nslookup' should do it.

I didn't look into this one yet.

James J Dempsey <> sent the man page (included attachment)
for xrsh (which he wrote) which I will definitely use for other things.
> You should try the xrsh script that I wrote and that is a part of the
> contrib sources for X11R5 and X11R6. You can also find it on
> in the contrib/utilities directory as xrsh-5.8.shar.gz.
> I'm enclosing the man page.
> --Jim Dempsey--

Dan Stromberg - OAC-DCS <> wrote...
> (Early, like SunOS 4.1.x and Ultrix) BSD tosses anything after the
> 16th character. SysVR4 (and perhaps earlier) keeps more in wtmpx.
> The most reliable way, is to rsh to the remote host, and start an
> xterm with the -display option. I rely on this mostly.
> As a fallback, I use this (in bash syntax, but should work in any
> recent bourne-based shell). As you can probably tell, it's geared
> toward machines with the suffix.
> function setDisplay
> {
> # bringing up a remote xterm with rcmd should set the display automatically
> if [ "$DISPLAY" = "" ]
> then
> if who | grep '(' > /dev/null
> then
> # not exactly an ideal solution, but it works in most cases
> local adr TTY
> TTY="$(tty | sed 's#/dev/##')"
> adr="$(who | \
> grep "strombrg .*$TTY" | \
> tail -1 | \
> sed 's/^.*(\(.*\)).*$/\1/')"
> # This'll get all but the most obnoxiously long hostnames (and of
> # course, those from off campus). The dialin*.slip case is
> # more hackish than the rest, needed to get slip logins onto
> # BSD hosts.
> case "$adr" in
> * export DISPLAY="$adr":0.0 ;;
> *.uci.ed) export DISPLAY="$adr"u:0.0 ;;
> *.uci.e) export DISPLAY="$adr"du:0.0 ;;
> *.uci.) export DISPLAY="$adr"edu:0.0 ;;
> *.uci) export DISPLAY="$adr".edu:0.0 ;;
> *.uc) export DISPLAY="$adr" ;;
> *.u) export DISPLAY="$adr" ;;
> dialin*.slip) export DISPLAY="$adr" ;;
> *.) export DISPLAY="$adr" ;;
> esac
> echo DISPLAY guessed to be $DISPLAY
> else
> echo DISPLAY not guessed - system has an uninformative who command
> fi
> else
> echo DISPLAY preset to $DISPLAY
> fi
> }

I have too many combinations of DNS names to play games like that.

        For now I am using a modified version of Donald McLachlan's bourne
shell script displayhost. Mine is called "gxdisp" for "Get X display".
Later if I can get perl on all the architectures I support the I will use
the perl version of displayhost. xrsh and xrlogin look great for some
other stuff I'm doing but don't solve the problem of Mac's and PC's only
UNIX-to-UNIX. I'm including all the following stuff below as attachments
so I don't get a thousand request messages...

Donald McLachlan's bourne shell script
Patrick Nolan's Perl script displayhost.perl
My modified Bourne shell script gxdisp
The man page for xrsh

Thanks to...

garrett@athena.SDSU.Edu (Garrett D'Amore)
Eric De Mund <> (David B. Brown)
Patrick Nolan <pln@egret1.Stanford.EDU> (Olav Lerbrekk) (Eric Wampner ORL)
David Lawrence Oppenheimer <davido@phoenix.Princeton.EDU>
James J Dempsey <>
Dan Stromberg - OAC-DCS <>
Michael D. Reynolds /\ | \
Allen-Bradley Co. Milwaukee, WI USA / \ | |
Dept 818 CAM Operations Office /____\ _____ |----\
Voice: (414)382-3615 Fax: (414)382-2742 / \ | |
Internet: / \ |____/
uunet: uunet!tinman2!camg2.mfg!reynolds A Rockwell International Company
X-Sun-Data-Type: shell-script
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 61

# displayhost by (Donald McLachlan), 11/12/92
# USAGE: setenv DISPLAY `displayhost`:0

# get name of remote host from `who am i` (as in utmp/wtmp/lastlog)
# $host will be null, if not remotely logged in
set `who am i`

# if not remotely logged in
if [ "$host" = "" ]
        echo $host

# use $host to get a login host.socket pair from netstat
host_socket=`netstat | awk '{ print $5 }' | awk '/\.[0-9]+$/ { print }' | fgrep $host | head -1`

# get socket from $host_socket pair
set $host_socket
eval socket=\$$#

# use $socket to get hostip.socket pair from netstat
set `netstat -n | grep $socket`

# split $hostip_socket into parts
set $hostip_socket

# use hostip parts to get hostname from nslookup
nslookup << EOF | grep -e | awk '{ print $5 }'
        set type=any
exit 0
X-Sun-Data-Type: default-app
X-Sun-Data-Name: displayhost.perl
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 52

# Find the name of the host from which a user is logged in.
# This is necessary because utmp entries truncate the host name,
# often losing necessary information.
# USAGE: setenv DISPLAY `displayhost`:0
# Written by Patrick Nolan ( April 4, 1993
# Modified March 1994 based on suggestions by C Lance Moxley
# (
# Inspired by a shell script of the same name written by
# (Donald McLachlan), 11/12/92

#require 'sys/';
$AF_INET = 2;

# Use `who am i` to get the first 16 characters of the remote
# host name. This is a bit slow, but the alternative is rooting
# around in /etc/utmp, which is not portable and subject to
# oddities of the tty naming conventions.

$host = (split(/[\(\)]/,`who am i`))[1];

# If there's no valid host, then we are logged in locally. This is easy.

if ($host eq "" || $host eq ":0.0") {
   print `uname -n`;
   exit; }

else {

# This is a remote login.
# Use netstat -n to get the host address associated with each
# established net connection. Find the full hostname associated
# with each one. Take the first one which contains our partial
# hostname.

   foreach (`netstat -n`) {
     if (/ESTABLISHED/) {
       $adrs = pack("C4", split(/\./, (split)[4])); # Convert addrs to word
       $fullname = (gethostbyaddr($adrs, $AF_INET))[0];
       if ($fullname =~ $host) { # See if it matches partial host
         print $fullname,"\n";
   exit -1;
X-Sun-Data-Type: shell-script
X-Sun-Data-Name: gxdisp
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 79

# gxdisp 2.0 Allen-Bradley Co. D818 Michael D. Reynolds 07/08/94
# Script to set the DISPLAY environment variable. Add to .login or .profile.
# Usage: DISPLAY=`gxdisp`
if who am i | grep '(' > /dev/null
        # set host variable for processing
        host=`who am i | cut -f2 -d"(" | cut -f1 -d")" | cut -f1 -d":"`
        # not remotely logged in
        DISPLAY="`uname -n`:0.0"
        echo $DISPLAY
        exit 0
# Locally defined host (no dots)
if echo $host | grep -v "\." > /dev/null
        echo $DISPLAY
        exit 0
# Undefined Host (IP Address) Change to your network mask
if echo $host | grep "130.151" > /dev/null
        echo $DISPLAY
        exit 0
# DNS Defined Host (Donald McLachlan's stuff here)
set `who am i`
# use $host to get a login host.socket pair from netstat
host_socket=`netstat | awk '{ print $5 }' | awk '/\.[0-9]+$/ { print }' | fgrep $host | head -1`

# get socket from $host_socket pair
set $host_socket
eval socket=\$$#

# use $socket to get hostip.socket pair from netstat
set `netstat -n | grep $socket`

# split $hostip_socket into parts
set $hostip_socket

# use hostip parts to get hostname from nslookup
DISPLAY=`nslookup << EOF | grep -e | awk '{ print $5 }'
        set type=any
echo ${DISPLAY}:0.0
exit 0

X-Sun-Data-Type: default
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 256

                                  Release 6

      xrsh - start an X program on a remote machine

      xrsh [ -help ] [ -version ] [ -l username ] [ -auth authtype ] [
      -screen screen-# ] [ -pass envlist ] [ -debug ] [ -debug2 ] remote-host
      [ X-command [ arguments ... ] ]

      Xrsh runs the given X command on a remote host. It sets up the
      environment for that command such that it will display its windows on
      the current server's screen by propagating the $DISPLAY environment
      variable. If not specified, the default client is xterm. Xrsh
      automatically selects rsh(1), remsh(1) or rcmd(1) to execute remote
      commands, depending on what is available the O/S environment.

      Xrsh automatically handles authentication so that the remote client
      will be allowed to open windows on the server. It does this in
      several different ways depending on the value of the $XRSH_AUTH_TYPE
      environment variable or the -auth argument.

      By default, xrsh will use xhost to enable the remote client to open a
      server connection. It can also be told to use xauth to merge local
      keys into a remote authorization file. Or it can pass the
      $XAUTHORITY environment variable to the remote host in order to share
      a common NFS mounted authority file. It can also be directed to do
      nothing in the case where no explicit authorization is necessary.

      Users who just want a remote terminal window might look at xrsh's
      sister command, xrlogin(1). Xrlogin uses a locally running xterm to
      open an rlogin connection to a remote host. The decision on whether
      to use "xrsh host xterm" or "xrlogin host" should be based on several
      factors. If X is unavailable on the remote host or the local terminal
      emulator has better features, use xrlogin. In general, the author
      recommends using xrsh over xrlogin in most situations.

      If the command to execute on the remote host is an xterm, xrsh
      automatically passes the -name argument to xterm with a value of
      "xterm-hostname" where hostname is the name of the remote host. This
      allows the user to specify resources in their server's resource
      manager which are specific to xterms from a given host. For example,
      this feature can be used to make all xterm windows from a given remote
      host be the same color or use a specific font or start up in a
      specific place on the screen. Xrlogin passes the same string so they
      are compatible in this regard. This feature can be overridden by
      specifying your own -name argument on the xterm command line.

      If the command to execute on the remote host is an xterm, xrsh
      specifies that the default title for the new xterm will be
      "xterm@hostname" where hostname is the name of the remote host. This
      can also be overridden by specifying your own -title argument on the

                                    - 1 - Formatted: July 5, 1994

                                  Release 6

      xterm command line.

      Xrsh is very careful not to leave any extra processes on either the
      local or remote machine waiting around for the client to exit. In
      some remote environments (particularly some Sys V implementations of
      csh and rsh), this is impossible and xrsh should be run as a
      background command.

      Note that xrsh options precede the given X command and its arguments.

      -auth authtype
           Choose what type of X authorization (or access control) is going
           to be used. Authtype can be one of "xhost", "xauth", "xhost-
           xterminal", "environment", or "none". The default is xhost, but
           the default can be set by setting the value of the environment
           variable $XRSH_AUTH_TYPE.

           If xhost is specified and the X server is running on the local
           machine, xhost will be run locally to enable the remote host to
           open an X connection. If the server is on a third host (not the
           one where xrsh is running and not the one where you wish to run
           the command), rsh will be used to run xhost on the server host to
           authorize the host where the command will be run.

           If xauth is specified, then xrsh will merge the entries for the
           server from the local $XAUTHORITY file into that of the remote
           host using rsh.

           The authtype xhost-xterminal is intended for use by people using
           X terminals. If xhost-xterminal is used, then the first time
           xrsh is run, it runs xhost locally to enable the remote host for
           access. This should work since (theoretically) the first time it
           is run is on the XDMCP host for the X terminal. From then on it
           propagates the name of that host to all remote hosts via the
           environment variable $XHOST. In subsequent invocations from
           remote hosts, xrsh uses rsh to connect to the host $XHOST and run
           xhost to enable new remote hosts.

           Authtype "none" does no explicit work for access control. Use
           this if you don't enable access control or if you use another
           mechanism for access control.

           Finally, authtype "environment" automatically propagates the
           environment variable $XAUTHORITY to remote hosts, assuming that
           it is an NFS mounted location that can be accessed from all

           Normally xrsh redirects standard input and standard output to

                                    - 2 - Formatted: July 5, 1994

                                  Release 6

           /dev/null in an effort to cause unneeded rshd and shell processes
           to exit. As a result, the user can't usually see any errors that
           might occur (like a "Permission denied." from rsh). If you are
           having trouble getting xrsh to work with a remote host, try
           giving the -debug switch to see if any errors are being

           This switch causes xrsh to turn on the -x option in the shell so
           that the user can see every shell command executed by xrsh. Only
           use this script if you are debugging the xrsh code itself.

           Print out the argument list to standard output.

      -l username
           Use the -l switch to specify a different user name to use for
           logging in via rsh on the remote host.

      -pass envlist
           Envlist is a quote delimited string naming an arbitrary set of
           environment variables to pass on to the shell environment on the
           remote host. If one wanted to set $XRSH_AUTH_TYPE and
           $XAUTHORITY to the remote host, one could use: -pass
           "XRSH_AUTH_TYPE XAUTHORITY". A default set of environment
           variables to pass may be set using the environment variable

      -screen screen-#
           Specify a different screen on the server on which to display the
           remote client.

           Print out version information and exit.

      The environment variables XRSH_AUTH_TYPE and XRSH_ENVS_TO_PASS which
      can be used to set switch defaults are overridden if the equivalent
      switch is specified as well.

           The $XAUTHORITY environment variable is passed to the remote host
           if the authtype specified by -auth or $XRSH_AUTH_TYPE is

           This environment variable can be used to specify the default type
           of authorization or access control. The values it can be set to
           are the same as the values for the argument -auth.

                                    - 3 - Formatted: July 5, 1994

                                  Release 6

           If the environment variable XRSH_RSH_ERRORS is set to the name of
           a file, any rsh errors will appear in that file on the remote
           host. If that variable is unset, error messages will be thrown
           away unless the -debug switch is given. (Note: don't use ~ in the
           filename because it will expand to ~ on the local host, but try
           to put the errors in that file on the remote host.)


      Make sure your PATH environment variable on the remote host is set in
      your .cshrc or .bashrc so that rsh programs have access to it.
      (/bin/sh and /bin/ksh users have a hard time time here since their
      shells don't execute any init files under rsh. You can use the
      XRSH_ENVS_TO_PASS environment variable to pass the PATH environment
      variable to the remote host. Optionally, you can type a full path to
      xrsh in that case. (E.g. xrsh remote-host /usr/bin/X11/xterm))

      Make sure your PATH environment variable on the remote host includes
      the directory containing the X programs. This is often /usr/bin/X11
      or /usr/local/bin/X11.

      Make sure you have rsh configured to work on the remote host. You can
      test this by typing: rsh remote-host echo '$PATH' This will prove
      that rsh works and show you the PATH that will be used on the remote
      host. If you get "Permission denied." you probably need to update
      your ~/.rhosts file on the remote host. See rlogin(1).

      xrsh yoda
           Start an xterm on the host yoda which displays on the current X
           server. Use xhost for access control.

      xrsh -auth xauth underdog emacs
           Start an emacs on the host underdog. Merge xauth authorization
           entries for this server into the authority file on the remote

      xrsh -l mjd -auth none -pass XRSH_AUTH_TYPE -debug tigger xterm -
           fn 5x7
           Start an xterm on the host tigger in a very small font, propagate
           the environment variable $XRSH_AUTH_TYPE to the remote host,
           login to the remote host using the id "mjd", don't do any
           specific authorization and don't redirect standard/error output
           to /dev/null so I can see any errors.

      If the values of the environment variables specified in -pass or
      $XRSH_ENVS_TO_PASS contain quote characters, xrsh will have

                                    - 4 - Formatted: July 5, 1994

                                  Release 6

      If the remote host can't resolve the hostname of the server host
      (through /etc/hosts, DNS or NIS), the remote client will not be able
      to open a connection to the server.

      System V users may need to make the first line of the script begin
      with colon (:).

      If you think you have found a bug, the first thing you should do is to
      check on in the contrib directory using anonymous FTP to see
      if there is a new version of xrsh there that already fixes the bug.
      If not, send email to "" and be sure to have the token xrsh
      somewhere in the Subject: line. Be sure to report the operating
      system type and version at both ends of the xrsh connection and a
      description of the command you are using and what authentication mode
      you are using.

      xrlogin(1), rsh(1), xhost(1), xauth(1)

      James J. Dempsey <> with help and suggestions from many
      people including,, and,
      <>, and

                                    - 5 - Formatted: July 5, 1994

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:05 CDT