Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
the prompt is not in colors, indicating that my .bashrc is not being used for root
The .bashrc is not read for login shells. So the fact that is not read when you invoke a login shell is the expected behaviour.
Extract from the bash man page:
Quote:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.
Edit:
It is fairly common practice to parse .bashrc from .bash_profile so .bashrc thus causing .bashrc to be used for login shells as well as non-login shells.
If you want to know what shell you're using you do this:
The solution will not involve recompiling the kernel nor changing my distro.
I think you mean that you would prefer a solution that doesn't involve recompiling the kernel or changing distro. Since you don't know what the solution is, you are not in a position to state that the solution will not involve either of these.
Last edited by arizonagroovejet; 10-24-2008 at 11:57 AM.
root won't use bash as the login shell. It uses sh. I verify this by two means:
the prompt is not in colors,[/code]
Completely irrelevant. The prompt can be set on a per-user basis, and usually root uses a different prompt. It's indicative of nothing at all.
indicating that my .bashrc is not being used for root
As the other poster above said, bashrc is not always read. It depends if it's a login or non-login shell. Read the section titled "INVOCATION" of the bash man page.
Quote:
when I run screen and perfrom a ^-a " operation, the menu shows "sh", not "bash" for each screen name
I don't know where does screen takes that info from. However, note that in most modern distros, /bin/sh (or /usr/bin/sh, or whatever) is usually a symlink to /bin/bash. You can check if that's your case with "ls -l /bin/sh".
Quote:
Use of the chsh command indicates that root uses bash but it lies, as already determined above.
This command, and the contents of /etc/passwd never lies.
If I start a new root via su from a non-root term, this new root does use bash.
Quote:
How do I force root to use bash? The solution will not involve recompiling the kernel nor changing my distro.
Standard procedure. The kernel is unrelated, as is the distro for the most part. It's the login manager which launches a given shell or desktop.
From the information in the helpful replies, it has been determined that there is, in fact, no sh on my system. It's all bash .,.. yet somehow bash acts differently, not reading certain files or reading certain files based on ... still parsing that. Very strange. As the nature of the problem has changed, it will have to go to another thread.
From the information in the helpful replies, it has been determined that there is, in fact, no sh on my system. It's all bash .,.. yet somehow bash acts differently, not reading certain files or reading certain files based on ... still parsing that. Very strange. As the nature of the problem has changed, it will have to go to another thread.
All you need to know regarding what files are parsed is in the bash man page, INVOCATION section as I said above.
Some things to note are the following:
As said, depending on whether the shell is a login shell or a non-login one, the parsed files are different.
Some times, bash will not parse file Y if file X has been found first, even if X is an empty file. For example, when bash is invoked as a login interactive shell, it reads /etc/profile, and *after* that, it reads one (and only one!) of ~/.bash_profile, ~/.bash_login, and ~/.profile. They are probed in that order, and the first one that is found (and readable) will be used. That means that, if ~/.bash_profile do exist, then ~/.bash_login and ~/.profile will not be read. Even if ~/.bash_profile is an empty file.
For non-login shells, ~/.bashrc is sourced.
Check very carefully the ownerships, permissions and special attributes of the bash init files in each home directory (your user's and root's) and see if they are coherent. Be specially careful and check also if any of these files is a symlink to any other file, sometimes people do odd things, and then they just can't figure why they seem to have a mutant bash.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.