🚀 go-pugleaf

   I am using Ultrix 4.1 on a DECstation 5000, UWS version 4.1
   with the following in /etc/ttys to start the X server and
   hang the Xprompter on the console instead of getty:

     :0 "/usr/bin/login -P /usr/bin/Xprompter \
	 -C /usr/bin/dxsession" none on secure \
	 window="/usr/bin/Xtm -bs -su"

   I would assume that somewhere along the line, a login csh
   will get exec'd by /bin/login, and read the $HOME/.login
   file for csh users. But this doesn't happen. The .login
   file is ignored.

   ____________________________________________________________________________
   pms415!reso@fmsrl7.srl.ford.com             sevihc!reso@sharkey.cc.umich.edu
   RESO -ON D1D1                               {sharkey|hela}!sevihc!reso
   Ford - Car Product Development, CAD/CAM     Sterling Heights, MI USA
   Bldg3 1st Floor #1152 (313) 322-5867        (313) 939-2789

I have a rather bizarre workaround to get this to work correctly.
It is not what I would call a clean solution to this problem,
by any stretch of the imagination.  If you are interested, I can
mail you the dot files used.  

My complaint with the default is that *IF* you change to a different
window manager, (twm in my case) the window manager does not get the
environment that a login shell would get, so that stuff like
configurable menus (f.exec "...&") has to have entire path coded in,
if that binary is not installed in the standard path.  

This is ok in a single vendor environment, but here, with many vendors
all placing binaries all over the place in the filesystems (and having
my home directory nfs mounted, of course), you cannot hardcode the
paths in the twmrc.  This sort of thing is a real pain in situations
where all your dot-files are on nfs-mounted systems, and involve
multiple architectures and vendors.  My attempts at getting past all
the differences with one set of dot-files have resulted in a fairly
convoluted login sequence.

My solution essentially involves two .logins, one of which is used by
the session manager to start the window manager, and set up a minimal
environment for the window manager.  The other (the real one) is used
by shells starting up in each of the windows, and all other machines.


JHH
--
Disclaimer:  I didn't do it.
Jim Hudgens		Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu