[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: No sourcing of ~/.profile at login

Daniel B. wrote:
> Why doesn't it (or some part of the GDM/etc. login process) know your 
> default shell the same way /bin/login knows (and invokes an instance 
> of) your default shell?

It does seem like it should be able to know that.  But of course it
won't know about my own whizzy furblyburb shell.  So maybe it is best
if it does not try.

> > Why doesn't Xsession load .profile directly?  /bin/sh is used by
> > Xsession to start up your environment.  If you are a bash user and
> > source /etc/bash_completions in your .bash_profile then /bin/sh would
> > have syntax errors trying to read it and you would be logged out.
> Did anyone suggest that Xsession should load .profile directly?  

Looking back through the messages:

> Daniel B. wrote:
> > Why not?  (Why shouldn't logging in via GDM execute your login-time
> > shell initialization?)

That implied to me the .profile.

> Something (I don't know if that would be Xsession or something else)
> should start your preferred shell with the login-shell options just
> as /bin/login invokes it.

That would be a good question for the kde and gnome lists.

My preferred login method for years was the terminal console and I
would run 'xinit' when I wanted to start up X11.  But new people today
usually approach gnu/linux from other graphical environments and they
don't find the character terminal an acceptable login method.  Most
people are preferring the graphical login now and I am finding myself
needing to adapt my own ways for this.

> > Basically if Xsession did load $HOME/.profile then any errors there
> > would prevent the login from happening.  I am sure the Gnome/KDE folks
> > just got too tired of seeing bogus bug reports about gdm/kdm not being
> > able to log people in and avoided this by this process.  
> Breaking standard Unix login is NOT acceptable.  Why didn't they just
> have the "safe" mode suppress reading any startup files that could
> prevent login?

I don't know.  I was not there when this was implemented.

Not liking the current behavior myself I implemented one that did
source the user's .profile.  It was a disaster.  An error in the
profile is bad enough normally.  But worse when compounded by a layers
of programs around it.  Basically the users would frequently not be
able to log in nor would they be able to deduce the problem from the
failsafe mode.  I eventually decided that perhaps the gdm/kdm behavior
was not so bad after all and recalled my implementation and restored
the default kdm.  The .xsession solution works well and you don't have
to have two environment scripts if one sources the other.

It would be nice if this were one of the /etc/skel files so that by
default this was preconfigured for users.


Attachment: pgpTpZpTwVaap.pgp
Description: PGP signature

Reply to: