Unix/Linux Go Back    


Fedora is an operating system centered on the Linux open source kernel and is developed by the community-supported Fedora Project. Fedora is sponsored by Red Hat. Fedora contains software distributed under a free and open-source license. Fedora focuses on innovation, integrating and adopting new technologies and working closely with various Linux communities. The default desktop in Fedora is the GNOME desktop environment and the default user interface is the GNOME Shell. Other desktop environments include KDE Plasma, Xfce, LXDE, MATE and Cinnamon. Security is an important aspect of Fedora with one specific security feature, Security-Enhanced Linux, implementing a variety of software security policies, including mandatory access controls.

.bashrc in Ubuntu 14.04

Fedora


Closed    
 
Thread Tools Search this Thread Display Modes
    #8  
Old Unix and Linux 10-21-2015
bakunin bakunin is offline Forum Staff  
Bughunter Extraordinaire
 
Join Date: May 2005
Last Activity: 22 January 2017, 5:48 AM EST
Location: In the leftmost byte of /dev/kmem
Posts: 5,300
Thanks: 94
Thanked 1,432 Times in 1,066 Posts
Quote:
Originally Posted by cmccabe View Post
EDIT: is adding path to .profile better
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

Last edited by bakunin; 10-21-2015 at 04:23 PM..
Sponsored Links
    #9  
Old Unix and Linux 10-21-2015
MadeInGermany MadeInGermany is offline Forum Advisor  
Registered User
 
Join Date: May 2012
Last Activity: 22 January 2017, 10:21 AM EST
Location: Simplicity
Posts: 3,367
Thanks: 259
Thanked 1,103 Times in 999 Posts
Wrench Experts question: where add things to PATH?

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?
Sponsored Links
    #10  
Old Unix and Linux 10-22-2015
bakunin bakunin is offline Forum Staff  
Bughunter Extraordinaire
 
Join Date: May 2005
Last Activity: 22 January 2017, 5:48 AM EST
Location: In the leftmost byte of /dev/kmem
Posts: 5,300
Thanks: 94
Thanked 1,432 Times in 1,066 Posts
@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.

Quote:
Originally Posted by MadeInGermany View Post
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.
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
Sponsored Links
Closed

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Linux More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
unset .bashrc cokedude UNIX for Advanced & Expert Users 9 03-16-2011 03:42 PM
bashrc lassimanji Shell Programming and Scripting 2 04-24-2009 03:40 PM
how do i look for my .bashrc file npatwardhan Shell Programming and Scripting 12 01-28-2009 02:43 PM
/etc/bashrc umask itik Ubuntu 3 12-10-2008 03:21 AM
from bashrc to sh..?? moxxx68 Shell Programming and Scripting 3 09-13-2004 06:39 AM



All times are GMT -4. The time now is 12:26 PM.