SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When I open a terminator I get this prompt: bash-4.1$
which does not include my .bashrc settings. If I then do a "su - spoovy" my prompt turns to: spoovy@darkstar:
which is fine. When I do a "su -" to change to root shell, I tend to Ctrl+D to go back to my user shell. Only it doesn't, it goes back to my "bash-4.1$" shell.
I don't know what's going on here i'm afraid. Why isn't my .bashrc read when i open a terminal? And why does it drop back to this 'blank format' shell all the time?
# .bashrc
# Add bin to path
export PATH="$PATH:/sbin:/usr/sbin:$HOME/bin"
# Add color
eval `dircolors -b`
# User defined aliases
alias ll='ls -la'
alias lsg='ls | grep'
alias llg='ls -la | grep'
I am (possibly incorrectly) assuming this is an artifact of starting a non-login shell instead of a login one. See `man bash` and search for INVOCATION. .bashrc is only read when a non-login shell is opened. ~/.bash_profile (and /etc/profile) are only read when a login shell is started. The default user@host:directory$ PS1 variable is exported in /etc/profile, which is only read when starting a login shell. Note that starting a login shell will NOT automatically read .bashrc as well -- and hence I have
Code:
#!/bin/sh
if [ -e ~/.bashrc ]; then
. .bashrc
fi
in my ~/.bash_profile
I always launch login shells just to make things easy, but you can probably add
Code:
. /etc/profile
to your .bashrc (before most other things I would imagine, since /etc/profile may override any .bashrc customizations if you source it last) to get everything working as expected in a non-login shell.
You must think of your usage scenarios and how you differentiate between login and non-login shells when constructing your .bashrc and .bash_profile files. If you don't differentiate at all, then you're safe sourcing the other file; if you do though, it may require a more complex setup.
I actually thought it was the other way round, that "su -" started a login shell, which in my case does source my .bashrc, whereas "su" starts a nonlogin shell. I need to swot up on all this, I remember being confused by it all when I last looked into it a long time ago.
I do already have a .bash_profile with those same lines in by the way.
su - user (a.k.a su -l user) does start a login shell. Login shells run /etc/profile, followed by the ~/.bash_profile or ~/.bash_login or ~/.profile
su user runs a non-login shell which (assuming it's bash) will run ~/.bashrc.
When you start a terminal or xterm, it will normally run a non-login shell and that should run .bashrc but not the profile files.
Also be aware that su in slackware 13.1 is broken and that may cause problems under certain circumstances. I've patched it here locally to get it working properly and reported the problem to Pat a while ago, but I'm sad to say that he's not done anything about it yet in either current or stable.
Anything you want to be available to all interactive bash shells, such as your aliases and PS= string: put in your ~/.bashrc
Code:
PS1='\u@\h:\w\$ '
alias ls='ls --color'
And then to make sure that's also run for interactive login shells, call it from a ~/.bash_profile such as:
Code:
case $- in
*i* ) # We're interactive
if [ -f ~/.bashrc ]; then # run ~/.bashrc if it exists
source ~/.bashrc
fi
;;
esac
The case statement ensures that it only gets run for interactive login shells and not non-interactive login shells.
By 'blank format' do you mean the "bash-4.1" prompt? If so then I notice that you don't actually set PS= in your .bashrc above.
Sometimes it helps when trying to debug these things to put a echo "running .bashrc"
in your bashrc script, and a similar one saying bash_profile in your .bash_profile. That way you can clearly see what's going wrong and at what stage.
You know, I don't have PS variable set in either :-P . But its deffo not sourcing my .bashrc as the color aliases don't work in my "blank format" shell.
So where is it getting "spoovy@darkstar:" from when I start a login shell anyway??
I did as you suggest re the echo commands. When I "su - spoovy" from within a shell I get both .bash_profile and .bashrc sourced. When I open a new, fresh terminal, neither is sourced, hence the "blank format" of "bash-4.1".
When everything is working, it is a login shell that has sourced /etc/profile, which in turn sources the *.sh scripts in /etc/profile.d/, including /etc/profile.d/coreutils-dircolors.sh, which properly sets colours. PS1 is set in /etc/profile itself. In /etc/profile.d/coreutils-dircolors.sh, it sets LS_OPTIONS to "--color=auto" by default. Though you are running `dircolors -b` in your .bashrc, ls is still defaulting to --color=false I believe (though this is a guess). As I said before, putting
Code:
. /etc/profile
in your .bashrc will likely clear everything up, as would launching your terminal as a login shell instead of an interactive non-login one. If your .bashrc really isn't being sourced when launching your terminal as an interactive non-login shell then something is wrong...
Please define what you mean when you say 'new fresh terminal'. xterm? konsole? xfce-terminal?
What happens if you just type 'bash' at the command line? does it run your .bashrc then?
Perhaps you can talk us through it step by step so we understand exactly what it is you're doing.
I respectfully disagree with T3Sliders advice. the profile files are intended to contain things that run only once in a session, it's not meant to be run for every new shell, so sourcing it from .bashrc is exactly the opposite of what it's intended for. Slackware itself puts things in /etc/profile and by extension /etc/profile.d that really don't belong in there (the aliases and PS prompts being a prime example), so I can understand why T3 is suggesting you do that, but it's a case of attempting to use two wrongs to make a right.
Besides, if you say it's not running you .bashrc at all, then sourcing /etc/profile from it really isn't going to help.
edit: Ahh I see you've done what T3 suggested and it's now working, so clearly it was sourcing your .bashrc after all.
To clarify things then, for your information if you want it..
*Previous to adding ". /etc/profile" to my .bashrc - *
I would open a terminator using dmenu. It would open with the "bash-4.1" prompt, and with no color in the ls commands. So, in order to get my colors and recognisable prompt I had to type "su - spoovy" and enter my password, in order to open a new login shell. This would then have "spoovy@darkstar" in the prompt, and my colors would be there.
If I needed to become root, I would "su -" which would then give me "root@darkstar" prompt, and a normal root shell. If I then pressed Ctrl+D it would print "logout" and return me to "spoovy@darkstar". If I pressed Ctrl+D again, it would print "exit" and return me to the "bash-4.1" prompt, and no colors.
*Since adding ". /etc/profile" to my .bashrc, and the 'troubleshooting' echo commands, - *
Now, when I open a new shell, it does print "sourcing .bashrc", and give me the "spoovy@darkstar" prompt, and colors. When I type "bash" in that same shell, it echos the same "sourcing .bashrc" and returns the same prompt.
So it appears to me that there were two things that were throwing me. A new terminator shell was sourcing my .bashrc all along, but not the color element, as T3Slider described. It also wasn't showing my username in the prompt as I hadn't set PS variable in my .bashrc (an oversight on my part).
I respectfully disagree with T3Sliders advice. the profile files are intended to contain things that run only once in a session, it's not meant to be run for every new shell, so sourcing it from .bashrc is exactly the opposite of what it's intended for. Slackware itself puts things in /etc/profile and by extension /etc/profile.d that really don't belong in there (the aliases and PS prompts being a prime example), so I can understand why T3 is suggesting you do that, but it's a case of attempting to use two wrongs to make a right.
I looked through all of /etc/profile and all of /etc/profile.d/*.sh. Most variables are set explicitly from /etc/profile and then added to in /etc/profile.d/*.sh. Unless I am mistaken, there are no side effects (things are reset unnecessarily when they should be inherited but there isn't really a downside) -- with the exception of the following variables:
which will have duplicated paths when /etc/profile is sourced from a non-login shell (or when running multiple login shells). It appears as though aliases are not preserved in subsequent shells (and PS1 gets reset by bash itself), so setting the following in .bashrc will allow you to maintain a proper environment without running a login shell:
Code:
alias d='dir'
alias dir='/bin/ls $LS_OPTIONS --format=vertical'
alias ls='/bin/ls $LS_OPTIONS'
alias mc='. /usr/share/mc/bin/mc-wrapper.sh'
alias v='vdir'
alias vdir='/bin/ls $LS_OPTIONS --format=long'
PS1='\u@\h:\w\$ '
export PS1
Untested and keep in mind I am using Slackware 13.0, so any changes between 13.0 and 13.1 are unaccounted for.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.