Micha Feigin said: >> Well I can appreciate having separate profiles for sh and bash. I have >> cron >> jobs and cgi scripts that need a certain consistent environment that >> differs >> from the environment used for development. But the problem is I cannot >> seem >> to locate the mechanism to trigger all shells derived from a user logon >> to >> be logon shells. Such a mechanism must exist or there would be no point >> in >> having separate profiles. Or perhaps disperate packagers are not >> coordinating? >> > > The difference between login shell and non-login shell is more > historical, if you look at console work. Most xterm-like programs allow > you to control whether the shell is a login shell or not, but if you do > su <user> in that window then you will never get a login shell. > > There is a switch to the shell (for bash,sh its -l) to force a login > shell if you want. > > I just have my .bash_profile and .bashrc do the same thing (I don't > remember which calls what, but everything uses the same settings in the > end). > > If your cron jobs don't run as the regular user you can set the > settings for them in /etc/bash_... and override them for the regular > users in ~/.bash... otherwise maybe a check such as debian does for the > prompt will help you (check in the /etc/ files) it checks what kind of > environment you are in.
So what you're saying is their is no mechanism to change the behavior of all shells derived from a logon session and that the observed behavior is not a mistake and that the "proper" method is to simply lauch shells with the appropriate flags depending on the desired behavior? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
