Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!uupsi!rpi!rpi.edu!tale From: tale@turing.cs.rpi.edu (David C Lawrence) Newsgroups: comp.windows.x Subject: Re: xdm => bug (or should I call it an insect) Message-ID: Date: 17 Aug 90 08:31:28 GMT References: <9008160412.AA18389@xenon.lcs.mit.edu> Organization: Rensselaer Polytechnic Institute Computer Science, Troy NY Lines: 27 In <9008160412.AA18389@xenon.lcs.mit.edu> keith@EXPO.LCS.MIT.EDU (Keith Packard) writes: a) invoking xterm -ls as the user session. xterm -ls creates a login shell process which should read the file. It has been my experience here that the main problem people would have with xdm as opposed to their own startx is that they didn't have their environment variables set up -- I feel victim to it myself when things I started up from twm didn't have PRINTER, EMACSLOADPATH, MANPATH or even just PATH right, the last causing some programmes I had in my menus to not even be found. Just having an initial xterm client read it doesn't help a window manager started from the session initialisation. b) including code in Xsession which checks the shell of the user, and invokes a separate session program which reads the file I don't think I would do this to them; this would probably necessitate changes in many of their login files. Many people I know set up login scripts that are very login(1), tty oriented. Of course they could change them so they weren't, but as long as they are doing that why not just have them break out their special stuff another way? All I did was move my environment variables to a .env file which I source from my .Xsession and .bash_profile. -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))