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. Bob
Attachment:
pgpl3xTkPwXPg.pgp
Description: PGP signature