Conference turris::digital_unix

	If you're worried about security, then hardcode into your
	.login or equiv the setenv to your workstation.  This is
	what I do.

    This is what I used when I am logged from home.
    
    kamlia 32% more ~/bin/mytkpostage
    #!/bin/csh 
    #
    
    set remnode = `who -mM | cut -d \( -f 2 | cut -d \) -f 1`
    
    tkpostage +beep -bg black -display ${remnode}:0.0 &
    
    

    Of course I need to set "xhost kamlia" from my home node.  I could
    add that into the wrapper over rlogin/telnet but I am only interested
    in very *few* xapplications running remotely over the phone line.
    
    In the 10MBs ethernet environment I use couple of co-operating shell
    scripts and rsh commands to set up the display environment as a part of
    starting the xterm window on that node.  It is extremely ugly and
    probably reflects on my immaturity as a hacker :-)
    
    - Vikas

    who -mM will tell you the immediate source of the connection,  but not
    the ultimate source if you go through a second hop. In addition, as
    you've noted, the output field size is limited, so you sometimes get
    truncation of the host/domain.
    
    I use ksh, and my solution is first to use "who -mM" on Digital UNIX
    and then process its output to reconstruct any missing portions of the
    domain. I then process this together with the output of qterm to guess
    whether the remote terminal is an X-based terminal emulator, and, if
    so, set DISPLAY to the remote host.
    
    To handle multiple hops, a function "rl" in my .profile/.kshrc replaces
    "rlogin" and passes the remote host name or DISPLAY variable along with
    a small number of other critical environment variables encoded into the
    TERM variable. This is then picked apart again by a matching
    .profile/.kshrc on the remote host.
    
    The .profile/.kshrc and support files I use are in
    ftp://ftp.see.mro.dec.com/pub/login/ . It's supremely ugly in many
    places, reflecting the maturity of _my_ hacking, and has a lot of dead
    comments, but it works on Digital UNIX, Ultrix, SunOS, Solaris, HP-UX 9
    & 10, and Linux with the native ksh, if applicable, and with pdksh. The
    version above is missing a couple of minor adjustments for Linux. If
    you use any of it, you'll probably need some localization (or maybe an
    antacid :-) ). See the comments at the end.
    
    -Tom

It hadn't occurred to me that who's -m and -M options, if combined, would
be anded together rather than ored (orred?)  Even rereading the man page
doesn't make it clear that this would work.  I wonder if "man -mM" is really
reliable this way, or if we can anticipate its behavior changing in future
releases so that multiple lines are produced?

As for starting a remote xterm; I've found that it's usually better to start
the xterm locally and give it "-e rlogin" etc. on its command line.  There 
are at several common problems with running xterm (or any other terminal
emulator) remotely.  One is that you have to get the remote $DISPLAY right
first, and if you've used a chain of rlogin or telnet commands to get there,
this may not even be possible.  Another is that you're sending scan lines
across the network (24 bits per pixel), and if the network is slow, the
xterm is *very* slow.  Running the xterm locally causes only the ascii bytes
to go across the network, which is much faster.  And there are far too many
vendors who either don't supply xterm or put it outside the default search
path, to encourage you to use their "improved" terminal emulator; in a mixed
environment, this can get to be a real hassle.  ("OK, where did the turkeys
hide xterm on *this* machine?" ;-)  And there are various minor problems due
to the inconsistencies among various releases of xterm; if you run it locally,
all of them will behave the same.

What I prefer is to write a wrapper script for rlogin and telnet; the script
that I call "Rlogin" just looks like:
	xhost + $1
	xterm -e rlogin $* &
and the "Telnet" script is similar.  The one remaining problem is that the
technique for setting $DISPLAY on the other end (if you need it) is different
for every vendor.

#!/bin/csh
# This script uses the "who" command to find out where the process came from
# and the protocol.  This is used to set the DISPLAY environment variable.
# The following (as returned by "who") are understood:
#
# "who" return          Deduced Transport
# (node)                TCP/IP
# (node.msk1.msk2.msk3) TCP/IP
# (DEC:.area.node)      DECNET
# (number.number)       DECNET
# (node/UIC_number)     LAT -- DISPLAY not set
#
# Edit History:
# Name Date             Comments
# ---- ---------------- --------------------------------------------------------
# cen   6 Nov 1996      Created
#

if ($?DISPLAY != 0) then
else
set my_host=`who -Mm`

if (`echo $my_host | awk -F' ' '{print NF}'` >= 6) then
set my_host=`echo $my_host | awk -F' ' '{print $NF}' | sed 's/(//; s/)//'`

if (`echo $my_host | egrep -c '^DEC:\.[a-zA-z0-9]*\.[a-zA-z0-9]*$'` == 1) then
# DECnet of the form DEC:.mumble
set my_host=`echo $my_host | awk -F'.' '{print $NF}'`
setenv DISPLAY ${my_host}::0.0
else if (`echo $my_host | egrep -c '^[0-9]*\.[0-9]*$'` == 1) then
# DECnet of the form #.#
setenv DISPLAY ${my_host}::0.0
else if (`echo $my_host | egrep -c
'^[a-zA-z0-9]*\.[a-zA-z0-9]*\.[a-zA-z0-9]*\.[a-zA-z0-9]*$'` == 1) then
# TCP/IP of the form mumble.mumble.mumble.mumble
setenv DISPLAY ${my_host}:0.0
else if (`echo $my_host | egrep -c '^[a-zA-z0-9]*$'` == 1) then
# TCP/IP of the form mumble
setenv DISPLAY ${my_host}:0.0
endif

endif

unset my_host
endif

>Another is that you're sending scan lines across the network (24 bits per
>pixel), and if the network is slow, the xterm is *very* slow.  Running the
>xterm locally causes only the ascii bytes to go across the network, which is
>much faster.

This is not true. Xterm would be sending standard X requests like XDrawString,
XDrawLine etc., not sending pixmap data. On a properly configured network,
running a remote Xterm is typically indistinguishable from a local Xterm. This
harkens back to the day's of old when standard Sun FUD against X was just this
sort of thing - it's sending pixmaps across the wire and is horribley slow :-)

			Pete