Hi Steven, Steven W. Orr wrote: I know what you mean. I have to do a lot of data analysis at the university and we use a really complex framework written in C++, called ATHENA. To ensure all the various sub-packages /behave/ with each other we use environment variables controlled with lots of sourced shell scripts. Its really amazing and extremely elegant way of controlling how things behave. :) Thank you for this entire reply Steven. All the subtleties you mentioned makes a lot of sense. Following these simple rules makes everything work consistently whether its being run from an xterm, VT or from a button on my desktop. I'll try to go over what you said again and try to keep those in mind while investigating any future issues and will definitely try to include any such information in any bug report I contribute to. Thanks a lot, learned a lot. :) -- Suvayu Open source is the future. It sets us free.

Jonathan Ryshpan <jonrysh <at> pacbell.net> writes: /org/gnome/Disp /var/run/gdm/auth- /usr/lib64/firefox-3.5.4/run-mozilla.s See this excellent post by Chris Tyler where he explores the sequence of events leading to execution of .bash_profile: http://dailypackage.fedorabook.com/index.php?/archives/122-Wednesday-Why-... The critical line is in the /etc/X11/xdm/Xsession script: exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session" where SHELL is bash. Allen

On 11/02/09 04:28, quoth Suvayu Ali: It is correct that the .bash_profile should source in the .bashrc but it is wrong for a terminal emulator to be executed as a login process to account for gdm's deficiency. First of all your .bash_profile should source in your .bashrc or else you won't get any of your bashrc content in your login process. Starting a login process must run your .bash_profile and starting a sub shell process must run the .bashrc This means that the .bashrc must be run by the .bash_profile or else the login process will never get any of your local aliases, functions and variable settings. This confuses a lot of people: * When you log in, the login process must define the environment. This is done by sucking in the ~/.bash_profile after the /etc/profile * The ~/.bashrc is sucked in automatically only by sub shells. To get bashrc content added to your login shell, the ~/.bash_profile must pull in the ~/.bashrc * The /etc/bashrc is not run by the system. The user is responsible for doing this himself. In your ~/.bashrc should be a line that says: . /etc/bashrc All of what I describe above is how things should be done, but it is *wrong* for the gdm login process to not run the correct files for you in the first place. That is why I have showed you how to go about the process of fixing it properly. You need to see about pulling in the /etc/profile and ~/.bash_profile from the /etc/X11/xinit system. You will *probably* be able to add a file (maybe call it) /etc/X11/xinit/xinitrc.d/00_bash_init.sh It should say something like what I mentioned above. I recommend *not* making it executable even though all of the files in /etc/X11/xinit/xinitrc.d are. This just confuses people more. Sourced files are not executed; they are read into a current shell. If you do it wrong then you will be putting a crappy bandage on a system that is capable of much elegance. The whole point of environment variables is to define what *all* child processes will inherit. Look at the env command. It's not about what you see as being used by bash. It's about what the getenv(3) and setenv(3) runtime calls make available to all child processes, irrespective of what language they are written in. The environment is agnostic about linguistics. Let's look at an example. In my environment, I define XFILESEARCHPATH and XUSERFILESEARCHPATH. If I do it then my applications will start up with the correct set of resources. If I don't then they will not. But what I will not accept is that I must start my applications from a terminal emulator that was artificially started with a --login option. That's just silly. If I want to create a button that run my application then I expect that button to be running in the proper environment that has those variables set to the values that I have defined. Make sense? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net

Hi Steven, On Sunday 01 November 2009 09:32 PM, Steven W. Orr wrote: What is your comment on the method I posted, have your .bash_profile source your .bashrc ? That way you have a consistent environment every time, irrespective of whether I am at an xterm or VT or simply running some GUI app from a menu or icon. (I am of course assuming my desktop environment sources my .bash_profile, as it should, when I login :) ) Would you say that is a proper way to do things? -- Suvayu Open source is the future. It sets us free.

On Sunday 01 November 2009 01:31 AM, Didar Hossain wrote: ... or put this in your .bash_profile and have everything in your .bashrc ;) if [ -f ~/.bashrc ]; then . ~/.bashrc fi -- Suvayu Open source is the future. It sets us free.

On Sun, Nov 1, 2009 at 8:04 AM, Mikkel <mikkel(a)infinity-ltd.com&gt; wrote: Stuff that you need defined irrespective of the type of shell should go in ~/.bashrc Didar

hi. I just want to report one issue which I just observed. In FC11 file browser, when I click Edit-> Preference the window disappears. I am wondering whether its some config issue or some bug ? I am using core 2 due, 4GB, ASUS notebook. -- This is an email sent via The Fedora Community Portal https://fcp.surfsite.org https://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=383456&t... If you think, this is spam, please report this to webmaster(a)fcp.surfsite.org and/or blame chandan_raka(a)yahoo.co.in.