Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Once a friend of mine (who is an experienced Unix/Linux user) told me that setting root's shell to something other than sh (i.e bash or zsh) might create problems, because some script might assume that the shell is sh and do something weird.

However, I think Ubuntu have default root shell set to bash, and Gentoo uses bash too. Can somebody bust the myth?

share|improve this question
up vote 12 down vote accepted

Yes. If system fails during booting you can log into root shell. If you have separate /usr some shells can fail to successfully start.

I'd advice to create account toor (uid 0, gid 0) with non-standard shell while left root with default shell.

share|improve this answer
This happened to me when I upgraded from FBSD 7.2 to 8.0 and I forgot to rebuild bash. I booted in single user mode to fix, but it only worked because /bin/sh was still linked to FBSD's fork of bourne and not bash. – gvkv Oct 3 '10 at 3:32
just to make things clearer, if I install say zsh and somehow /usr is damaged I will have problem? but my system have /bin/sh pointing to /bin/bash and bash itself, why wouldn't sh be affected? – phunehehe Oct 3 '10 at 10:52
Defaults for root "guarantee" that the system will boot - the upgrade guide will take care about being able to log into root at least. However it may not be the case for anything else. The solution is to duplicate root account by toor with non-default shell for everyday use and keep root as is. – Maciej Piechotka Oct 3 '10 at 17:19
zsh should not be in /usr/bin/ if it is it was installed wrong. all shells should be in /bin – xenoterracide Oct 23 '10 at 23:18
@xenoterracide: zsh on Gentoo is in /bin but keeps some files in /usr/share. Also I clearly stated that problem is during login during boot (when some service fails). – Maciej Piechotka Oct 24 '10 at 23:54

Should not be an issue.

Shell-script files explicitly encode which shell they are executed with. It is encoded in the first line or other programs or scripts execute a specific shell and give the shell script as argument.

The only program I can think of that uses the user account shell information (besides the login process) is procmail. Really funny if your user has set as shell /bin/false on the mailserver ... But you usually do not execute procmail as root.

Another candidate would be the lines in the crontab of root. I don't know what the policy of crond is which shell to use.

share|improve this answer
$SHELL gets usually set to /bin/sh by the crondaemon on startup. – echox Oct 2 '10 at 17:46

Scripts written for the bourne shell will most of the time run against BASH or ZSH or $foo without any problems.

On many Linux systems is no original sh installed, instead its often a symlink against /bin/bash.

If some scripts just "assume" that the shell is explicitly sh, they should be rewritten. Theres the shebang mechanism to choose which interpreter your script needs. If its the sh, the script should include #!/bin/sh as the first line.

Your default shell setting should not be relevant in this context.

share|improve this answer

I don't think changing root's shell would cause any trouble. I seem to remember some unices (maybe some BSD variants?) having tcsh as the default shell for root.

Root logins are rare anyway. Normally, you'd log into your own account and then su or sudo to root.

What matters is that root's shell should have as few dependencies as possible so as to be usable in a system reparation context. For example, it's a good idea to have a statically linked root shell; some distributions ship a statically linked version of bash or zsh or sash (a shell with many standard utilities built-in). However this isn't so important if your system can easily be booted from a rescue CD or USB drive.

share|improve this answer
For the dependency reason I think it makes sense to leave the shell as is so that a big system modification (like an upgrade) won't mess things up. I agree it's easy to fix with a live CD or USB, but I shouldn't have to fix it in the first place. – phunehehe Oct 24 '10 at 6:48

I would make note of the orignal entry for the shell in /etc/passwd. Worse comes to worse, you can boot off a live CD and change it back.

share|improve this answer
You can always boot to single user mode with boot parameters. No need to boot off a live CD. – polemon Oct 3 '10 at 6:22
@polemon Will single-user mode still work if root's shell is missing? – Michael Mrozek Oct 3 '10 at 9:40
@michael Mrozek: Yes, because you tell at the boot parameter what shell to execute. Usually shell=/bin/bash, etc. – polemon Oct 3 '10 at 18:25
@polemon Ah, handy. Thanks – Michael Mrozek Oct 3 '10 at 18:46

The login shell of a user does not affect the boot process. You can set this shell to whatever you want. Not all systems have bash and they work fine. Also if it's /usr/bin/zsh it was installed wrong, all system shells should be in /bin. You shouldn't, however, change /bin/sh to point to something other than the default (unless you know what you are doing) as many scripts have #!/bin/sh which usually points to bash, when they should have #!/bin/bash because they use bashisms and other behavior that won't work on zsh or dash.

share|improve this answer
oops sorry I made a mistake, actually on my computer both bash and zsh are in /bin – phunehehe Oct 24 '10 at 6:32

I have bash as default shell for root. I used zsh for some time, but then went back to bash. What shell you use, doesn't matter much.

It's only an issue, if more than one person has root access. In that case you may select a 'common denominator' which is usually bash, as this is the most widely used shell.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.