Strange Shell

[Aaron_VanAlstine]

Running 9.1, I used chsh to use bash (which is in my /etc/shells file). However, when I'm root, my terminal looks like this:

[root@box /usr/home/aaronvan]#

It defaults to whatever directory I am in. This is too messy and annoying. In a small window it can use half the line. Is there a config file I can modify so only the # will appear?

 

[Lorem-Ipsum]

For bash simply set your PS1 in your ~/.bashrc.

ie: PS1="# "

 

[wblock@]

Many people come to regret changing root's shell to anything other than csh(1).

 

[Aaron_VanAlstine]

Many people come to regret changing root's shell to anything other than csh(1).

Yikes. Why?

I don't seem to have .bashrc or .bash_profile in my home directory.

 

[Crivens]

Yikes. Why?

I don't seem to have .bashrc or .bash_profile in my home directory.

That is because bash is not part of the base system and thus is not assumed to be around. It is a port, an extra, to the system. In Linux, everything is a bash. And there is no line between what the base system is and where applications are allowed to be.

Once this one shell breaks, you are buggered up seriously and fumble for a boot medium. This is why root uses a shell which is part of the base system by default, because you will be in trouble once your /usr does not mount and then you have no root shell. Or if you happen to update the bash port to some bleeding edge version, which does some funny things or nothing at all.

You may find what you want to change in .cshrc in /root, but be careful what you change there. Being out of a working root access is no fun, especially when the machine is some time zones away.

 

[jb_fvwm2]

One other way, a... fix up a super prompt b... leave the root's shell as default, and each root login one can either 1... work slower with the tcsh/sh shell, or [ the USUAL case: ] #bash # (or whatever ) ... sort of like a "second login command." It is way easier than it sounds (although may cause some expected shell behavior in some circumstances).

 

[wblock@]

Many people come to regret changing root's shell to anything other than csh(1).

Yikes. Why?

For a start, most additional shells are installed in /usr/local. Boot in single user mode, and /usr is not even mounted. If you must have bash(1) as a root shell, run it from .cshrc and at least it won't lock you out when /usr is not available:

.cshrc

if (-f /usr/local/bin/bash) then
  /usr/local/bin/bash -l
endif

 

[jrm@]

For a start, most additional shells are installed in /usr/local. Boot in single user mode, and /usr is not even mounted. If you must have bash(1) as a root shell, run it from .cshrc and at least it won't lock you out when /usr is not available:

I'm not suggesting it's necessarily a good idea to change the root shell, but, correct me if I'm wrong, I don't think you will get locked out if /usr isn't around because you are asked what shell root should use.

Enter full path name of shell or RETURN for /bin/sh:

 

[wblock@]

Hmm. Yes, it does ask, but I'm sure I've seen reports of people getting locked out. Anybody want to test and document what happens?

 

[Beeblebrox]

If you plan on switching to bash as root, at least have the sense to use shells/bash-static, which will install into /(s)bin instead of /usr/local/(s)bin.

 

[Aaron_VanAlstine]

Based on other's judgement I will not to mess with the root shell. csh it is and ever shall be. I'll stick to bash as my user shell.

 

[jrm@]

Hmm. Yes, it does ask, but I'm sure I've seen reports of people getting locked out. Anybody want to test and document what happens?

I used vipw to change root's shell to /usr/nonexistant_directory/blah and booted into single user mode and was prompted for the shell. When I hit enter I was able to log in as root with /bin/sh as the shell.

 

[DutchDaemon]

As stated several times: if you want to use a non-base-system shell, assign it to the toor user, and give the toor user a password. Then you can either log in as toor at the console, or run su - toor as a wheel user. And yes, toor has the same privileges and status as root.

 

[AlexJ]

@Aaron_VanAlstine
If your setup is exposed to the wild internet then make a favor for yourself and restrict usage of the bash to particular/trustful user(s) only that isn't used for running any network daemons.
bash, gawk and other similar utilities are very powerful things that shouldn't be allowed for everybody.
If hacker/cracker get any ability to execute the bash - it is means he/she will be able to create legal backdoor that isn't traceable in default logs.
It just a matter of a few lines that need to be feed to the bash to turn it to a remote shell because it natively support networking.

For the root IMHO the best choice is the /bin/sh since it is a smallest shell, it calls faster and take less memory and since the root user used by a system also(!!!) it makes a sense to assign default shell for him as much simpler and smaller with both points of view - security and speed. It just a matter of typing a few symbols to call preferable shell from default one when one work interactively.

 

[jrm@]

As stated several times: if you want to use a non-base-system shell, assign it to the toor user, and give the toor user a password. Then you can either log in as toor at the console, or run su - toor as a wheel user. And yes, toor has the same privileges and status as root.

It's been stated several times, usually with vague threats that you will get locked out of your system. If you have access to the console you have to work pretty hard to lock yourself out. For example, if you changed the line

console none   unknown off secure

to

console none   unknown off insecure

in /etc/ttys then you will be prompted for the root password before entering single user mode. Even then, there are usually ways to recover. If you don't have access to the console and you can't login as the toor user and you don't have access to security/sudo, then you will likely have trouble.

I'm not suggesting @DutchDaemon's dogma suggestion is bad, but there is more than one way to skin a cat. If you want to use a different shell for the root user, then inform yourself of the potential issues and take appropriate action (e.g., if you don't have access to the console, make sure you can log in as the toor user with a base shell) to prevent them.

 

[chatwizrd]

Never have had an issue running root with bash shell the past 12 years.

 

[wblock@]

Never have had an issue running root with bash shell the past 12 years.

But, as they say in investments, "past performance is not a guarantee of future results".

 

[jrm@]

But, as they say in investments, "past performance is not a guarantee of future results".

Fortunately, configuring FreeBSD isn't analogous to playing the stock market.