Re: .xsession symlinked to .xinitrc?
Raul Miller <rdm@test.legislate.com> writes:
> Rui Zhu <zhurui@cs.tu-berlin.de> wrote:
> > I don't know if the situation has changed in slink about X start up
> > process, I only followed this list for a few days. But as in hamm, if
> > you have linked ~/.xsession to ~/.xinitrc (in fact you have your *own*
> > .xinitrc), the system wide /etc/X11/xinit/xinitrc -> /etc/X11/Xsession
> > won't got called (see /usr/bin/X11/startx).
> >
> > Is this *really* expected behavior? Some hints?
>
> I haven't looked at this particular case, but you also miss out
> on things like /etc/profile and ~/.profile (or ~/.zprofile if
> using zsh, ~/.bash_profile if using bash, etc).
>
> It would be nice to sit down and run through all the sorts of
> login techniques that are present and come up with a nice
> simple document (and perhaps a list of recommended changes to
> various pieces of software) on the right ways to accomplish:
>
> environment settings,
> shell aliases, shell completion maps, etc.
> sign-on messages,
> ssh-agent key management,
> x desktop initialization,
> adding a system to an existing x desktop,
> linux virtual console management,
> fast non-interactive shell processing,
> ...
Oops, it is really a lot of stuff here, which I've not deeply thought
about (my shallow experience :), thanks for pointing out so many brain
works.
> > +dpms, etc., which should have been called by /usr/X11/Xsession. (Is
> > this not a little weird, that user xinit stuff not in INIT file but
> > SESSION file?)
>
> .xinitrc is used by xinit (which is only run after you've logged in
> normally), .xsession is used by xdm (which replaces the normal login
> stuff). To make it even more fun, a lot of the normal stuff that happens
> at login is shell specific. [You might even think of xdm as providing
> its own shell -- your .xsession file.]
Personally I only use startx (xinit), because lots of works don't need
X and linux VC is also very nice. Thinking xdm just like replacement
of normal login stuff, as you said, makes me more easily to
understand those session files.
> It gets complex when you try and provide a consistent base environment
> which is represented through several different access methods. [say: xdm,
> getty, sshd, telnetd, and /bin/open -w from inittab (for some dedicated
> runlevel)]. And I've not even touched on the nfs environment issues
> [which we do nothing to manage -- you need consisten user ids across
> your network for this to work -- I think we're waiting for someone to
> write some gpled analogy to the andrew file system].
It seems more like a policy problem and personal favor not technical
one, though dealing with it correctly and consistently is not easy
either, in that there are also so many choices.
Regards,
Zhu Rui
Reply to: