On Mon, Feb 06, 2006 at 01:40:53PM -0200, Bruno Buys wrote: > Seems like the only file being sourced was /etc/bash.bashrc. I added > > . /etc/profile > > to it, then > > . $HOME/.bash_profile > > to /etc/profile. Now my bash_profile gets read, always. It already has a > test to check if I have a 'bin' dir on my home dir. > > Apparently the issue is solved, so thanks for everybody's inputs. But it > looks weird, to me. How come there's .bash_profile and .bashrc on my > home, that aren't read when the systems loads right to X? Or, I can't > set my env, when in X by any other means...
It depends how you get the shell to be executed when logging in via XDM/KDM/GDM etc. If you use xterm, the -ls (loginShell) resource governs this. A bit obscure, but understandable if you think it through... I think the history goes something like this.. .profile in the home directory was introduced as a way to get the /bin/sh to execute some commands at login. It was then reaslised that some commands are needed only at initial login (eg setting up the environment), and others (like customising the prompt) need to be invoked every time a shell was started. So one of the environment variables established in .profile could be used to configure a secondary script which was conventionally (at one time) called '.profile.' To cater for differing syntax in differing shells, alternative shells used their own naming scheme for these script files. To simplify system administration, shells were made to look for system wide versions in /etc.. The concept of 'logging in' was then complicated when graphical terminals were added via X as something of an afterthought to Unix. Networking was also an afterthought, so the possibility of other ways of logging in had to dealt with. Now there may be no shell invoked at all when you log in via XDM or equivalent, so your environment must be setup somewhere else, typically .xsession for (as the name implies) an X session.. The shell conventionally knows (or at least used to - havn't looked recently to see if this has changed) if it is being forked by the login process by a magic '-' prefix to argv[0] which was only added by 'login' processes, and this determined if the login script was executed. It used to be the case that a login shell showed up in ps(1) as '-sh'. On my Debian Sarge, logging in on a console tty and starting an xterm on an external X terminal produces: % ps af 2931 tty1 Ss+ 0:00 -bash 3190 tty1 S 0:00 \_ xterm -display ncd:0 3191 pts/0 Ss 0:00 \_ -bash 3197 pts/0 S 0:00 \_ bash 3198 pts/0 R+ 0:00 \_ ps af Which suggests to me that xterm is starting bash as though it is a login shell (-ls option). The last bash was started manually for contrast. Check the '-ls' option in 'man xterm' for more on this option... There may be other complications that I havn't kept up with, or are Debian or shell specific. It is something that usually takes a bit of trial and error to get right on a new system.. It is sometimes interesting to put a 'echo myname' on the first line of each of your script files to see which are being executed and in what order when you login in different ways... Might be nice to improve this some time - for example defining a standard filename and syntax for specifying the general environment initialization, and leave the shell scripts for shell specific customization... Regards, DigbyT -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
