Fedora

NO!

I will repeat what others have told you here already. Hopefully you get it when it is repeated a second time. There are several (separate) points:

1) DO NOT MODIFY FILES WITH "echo ... >>"
It doesn't matter if you write:

Code:

echo "this" >> .profile

or

Code:

echo "that" >> .bashrc

you should NEVER do that to ANY file. The reason is you have no clear conception of what the files content is before or after. This is why you should use an editor (nano, vi, whatever - just use an editor instead of your imagination, because your imagination is not good enough for the task).

It is true that it is possible to manipulate files that way. But you have to be absolutely sure what you are doing - and you are NOT. Do not try experts methods as long as you are not an expert. You do not start figure-skating with the triple toe-loop and expect staying unharmed if you try it nevertheless.

2) Manipulate your PATH correctly
The PATH-variable is a list of directories, separated by colons:

Code:

/path/to/dir1:/path/to/dir2:/path/to/dir3:...

This list of directories is searched for executables. Notice the profound difference between:

Code:

PATH="/some/dir"

and

Code:

PATH="$PATH:/some/dir"

The first one replaces the current value of PATH with "/some/dir", the second one adds "/some/dir" to the end of the current value. In light of what i said above: which do you think helps better achieving your goal? Attention, this was the bonus question!

3) Modify vital system configuration carefully
The way you modify starting- and environment-scripts has a "fire-and-forget"-style to it. An experienced expert always is aware that he could do something wrong and therefore secures a way to step back before he tries anything.

You goal might - ultimately - be to modify your .bashrc. In your shoes i'd first create a copy of the existing - and known to be working - file, like:

Code:

# cp ~/.bashrc ~/bashrc.before

and only then modify it. If - like in your case - the modification does not turn out to be correct - you simply copy it back and start over! Better yet, you do not only make a copy but try it out on the commandline before even attempting to modify any file. This way you can simply log off and log on again and have your environment restored to be intact:

Code:

# PATH=...whatever....
# echo $PATH

Btw., this not only applies to modifications of .bashrc. This is the mindset of a truly responsible sysadmin: whenever you do something, you first wonder what might go wrong doing it and plan/take precautions to alleviate such possible problems. Then, after careful planning, you do it. Finally, when everything went seemingly well, you test what you have done: if it really had the desired effect, if it didn't have any unwanted side-effects, if it did have any other effects (they may not be unwanted, but it is good to know they are there), and so on!

Experienced swimmers first test the waters and only then jump in with bravado. Otherwise your head might be in for an unpleasant surprise if the water is only 1ft deep instead of the expected 10ft, if it is ice-cold instead of well-tempered or whatever the unexpected circumstance might be.

Finally, to come back from the abstract musings about work in general, some concrete observation: setting the PATH is done in bashrc, either in /etc/bashrc if the setting should be system-wide or in ~/.bashrc in a certain home-directory if it only for a specific user. The reason this does NOT BELONG to a profile is that ~/.profile is called from the login process when you login. ~/.bashrc is called whenever a shell starts. If you log in once and then start 5 shells. You profile is executed once, but the bashrc file is executed anew for every instance of the shells you opened.

I hope this helps.

bakunin

As pointed out earlier,

Code:

PATH=${PATH}:/dir/to/add

in .bashrc can end up in multiple :/dir/to/add:/dir/to/add:..., because each nested shell runs another .bashrc at start-up.
Nothing to worry about, if there is no maximum length exceeded.
But isn't it worth to consider .profile as the better location? .profile is only run once in the first shell (login-shell). PATH is environment: a child shell will inherit it, nothing is lost.
Strange concepts like "dbus" in Linux break the native Unix parent/child relationship, but try to emulate it.
And don't the GUI/desktop/VNC/whatever logins run a login-shell?

@MadeInGermany: good question! My answer is a firm: that depends. ;-))

As i said earlier, .profile is executed once for every login(-shell), .rc-files (depending on the login shell ~/.kshrc or ~/.bashrc or even something else) are executed for every new shell. Whatever you want to execute every time you log in goes to the profile, whatever you want executed for every new shell goes to the rc-file.

True. In some environments i put a sort-of "reentrancy-protection" into my .kshrc to prevent that:

Code:

if [ "$NEVER_USE_THIS_VAR" = "" ] ; then
     PATH="$PATH:/dir/to/add"
     ....
     typeset -x NEVER_USE_THIS_VAR="Kilroy was here."
fi

But i have to say that nested shells happen rarely at my workplace. My typical environment consists of an X-server, mwm on top and many xterms. The login session starts the window manager via exec, so the shells in the xterms are each first-level shells because the login-process was replaced by the mwm.

I do not use "desktops" like KDE, GNOME or whatever they are called if i can avoid it, so i can say nothing about how these work.

bakunin