reso@fmsrl7.srl.ford.com (Dennis M. Reso) (01/30/91)
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.
One can always use the "-ls" flags with dxterm, for example,
to get the environment (or put everything in .cshrc). But
what of a single process that one would like to background
at login: you don't want one for every window you start
with "dxterm -ls".
The MWM window manager seems no better behaved than dxwm.
Is there something I'm missing in the above ttys line?
____________________________________________________________________________
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-2789mike@raven.uss.tek.com (Mike Ewan) (01/31/91)
In article <34338@fmsrl7.UUCP>, pms415!reso@fmsrl7.srl.ford.com (Dennis M. Reso) writes: |> |> 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. The only shells that start are in (d)xterms. I'm assuming that you have some environment variables set in .login that you want set globally for the session. |> One can always use the "-ls" flags with dxterm, for example, |> to get the environment (or put everything in .cshrc). But |> what of a single process that one would like to background |> at login: you don't want one for every window you start |> with "dxterm -ls". What I would do is replace the call to /usr/bin/dxsession in /etc/ttys with a csh script that sources the user's .cshrc and .login then exec's dxsession. |> The MWM window manager seems no better behaved than dxwm. |> Is there something I'm missing in the above ttys line? It's not the resposibility of the window manager to set up the environment. It just passes the environment in which it starts on to the clients. Mike -- Michael Ewan (503)627-6468 Internet: mike@raven.USS.TEK.COM Unix Systems Support UUCP: ...!uunet!raven.uss.tek.com!mike Tektronix, Inc. Compuserve: 73747,2304 "Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart
moss@cs.umass.edu (Eliot Moss) (01/31/91)
Look into .xsession rather than .login (or .profile if you like other shells). -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
hudgens@sun13.SCRI.FSU.EDU (Jim Hudgens) (01/31/91)
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.edubni@modulex.dk (Bent Nielsen) (01/31/91)
pms415!reso@fmsrl7.srl.ford.com (Dennis M. Reso) writes: -- stuff deleted -- >The MWM window manager seems no better behaved than dxwm. >Is there something I'm missing in the above ttys line? The window manager is NOT started from the /etc/ttys, but it is started by the session manager (dxsession), so you must have the following in your $HOME/.Xdefaults to start MWM and not the default dxwm. sm.windowManagerName: /usr/bin/X11/mwm (if the path for mwm is /usr/bin/X11) -- Bent Nielsen <bni@modulex.dk> A/S MODULEX Phone: +45 44 53 30 11 Lyskaer 15 Telefax: +45 44 53 30 74 DK-2730 Herlev Denmark
avolio@decuac.DEC.COM (Frederick M. Avolio) (01/31/91)
I put my .login stuff into .X11Startup. I do not have terminal emulators read .login (i.e., Ifire them up as if they are shell scripts not new logins since it seems silly to go through some things I do in my .login/.X11Startup more than once). Fred
libove@libove.det.dec.com (Jay Vassos-Libove) (02/02/91)
I believe that this thread is relevant to something I tracked down in the source code a while back... When a user logs in to a unix system the shell that gets started up is usually a "login" shell, which is very closely defined by how it is started up. It turns out that it is not possible to get a shell to be a "login" shell _underneath_ the X Session Manager under the Ultrix Worksystem Software and therefore have all applications inherit a path, environment variables, etc. The way dxterm's shells get the environment is by forcing the shells to think that they are login shells (which can be done) but this still leaves the window manager, x session manager, and any other application started from window manager or session manager menus without the user's login environment. If anyone is truly interested, I will go back to the sources and dig out the reasons why you can't make the session manager's parent shell a login shell. It has something to do with the way the /usr/bin/login program exec's the x session manager. This is, by the way, generic to unix - not just an ultrix issue. -- Jay Vassos-Libove libove@libove.det.dec.com Digital Equipment Corporation decwrl!libove.det.dec.com!libove Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine! Farmington Hills, Michigan and D.E.C. Can't have 'em!
mike@tekgen.BV.TEK.COM (Mike Ewan) (02/04/91)
In article <LIBOVE.91Feb1113344@libove.det.dec.com> libove@libove.det.dec.com (Jay Vassos-Libove) writes: >I believe that this thread is relevant to something I tracked down in >the source code a while back... > >When a user logs in to a unix system the shell that gets started up >is usually a "login" shell, which is very closely defined by how it >is started up. It turns out that it is not possible to get a shell to >be a "login" shell _underneath_ the X Session Manager under the Ultrix >Worksystem Software and therefore have all applications inherit a path, >environment variables, etc. [stuff deleted] However, if you run xdm instead of Xprompter you can do something like the following and assuming xdm runs a csh script called ~/.xsession: In ~/.xsession: !#/bin/csh source .csh_env dxsession In .csh_env put all your appropriate setenv's. If you start mwm and a dxterm in .xsession instead of dxsession, mwm will inherit the environment. I don't know for sure that dxsession will but I believe so. Mike