Default shell for root and users is different

Today found out, after a reboot, that root users has shell history (up arrow brings previous commands). However new added users don't have that convenience. Then found out that "root" uses "/bin/csh", while users use "/bin/sh", and they are not the same (not a symlink or same hash).

So I wonder if I could change my user's shell to csh and don't break my system, and what's the reason for using different shells for each.
 
So I wonder if I could change my user's shell to csh and don't break my system
Of course. Many alternatives are also available as ports: in https://www.freshports.org/shells

That being said, I use regular /bin/sh and I do have command history with the up arrow. No idea why it doesn't work for you.

But whatever you do, never ever change roots shell.
You can change it to /bin/sh, but don't use a shell from ports for root, indeed.
 
Moved my user from "/bin/sh" to "/bin/csh" and now I have all the history after reboot. No idea why sh doesn't have it, any way to check?
 
See 3.9.1. Changing the Shell
But whatever you do, never ever change roots shell.
I have been changing root's shell (to a statically linked /bin/ksh) for the better part of 25 years, and never had an issue.
I do that because, when the chips are down, and I'm sweating blood, as root, in single user mode, I don't want to be using an unfamiliar shell!
In fact, if I ever login as root, for any reason, I don't want to be faced with a shell that behaves in ways that are "abnormal" to me, and thus likely to cause me to make errors.
The only issues you have to be aware of is to make sure that root's shell:
  • has no dynamic dependencies (i.e. shared libraries) outside the root; and
  • is properly maintained (i.e. kept at current patch level).

 
The only issues you have to be aware of is to make sure that root's shell:
  • has no dynamic dependencies (i.e. shared libraries) outside the root; and
  • is properly maintained (i.e. kept at current patch level).
Yes, you're right. If you know what you do you can even change root's shell. But i believe it's better to tell people "Don't do it".
 
Then found out that "root" uses "/bin/csh", while users use "/bin/sh", and they are not the same (not a symlink or same hash).
They are entirely different shells, why would they be "the same"? One is a C Shell and the other is a Bourne compatible Almquist Shell. There are many different types of shell you can use.

So I wonder if I could change my user's shell to csh and don't break my system
Users can change their shell to anything they like. I personally like tcsh(1). Others like a Korn shell, or Bash, or Zsh. Only two types of shell come with the base OS; tcsh(1) and sh(1). And there are many other shells you can install via ports/packages. There's even an entire category for them: https://www.freshports.org/shells/

No idea why sh doesn't have it, any way to check?
Because FreeBSD's sh(1) only has a rudimentary history. The history is not persistent, it's not saved between sessions.

The default shell that's shown with adduser(8) can be changed too. Just run adduser -C and change it.
 
But whatever you do, never ever change roots shell.
Just to make absolutely clear the implications of that statement: If the shell for the root user cannot run during boot up then the host will fail to start and you will be in a recovery situation.

Changing the root shell introduces the possibility that the one selected will not be available when the system next reboots, either by removal or change of location following a pkg upgrade, or other misadventure.

If you want root to have a different shell when working on a host then either configure the toor user with that shell and use toor; or switch to your preferred shell after logging on as root.
 
If the shell for the root user cannot run during boot up then the host will fail to start and you will be in a recovery situation.
It doesn't have anything to do with this. All boot scripts are using sh(1) (all scripts as a matter of fact). Root's configured shell has nothing to do with this.

Changing the root shell introduces the possibility that the one selected will not be available when the system next reboots, either by removal or change of location following a pkg upgrade, or other misadventure.
Problems typically occur when upgrading to a new major version. In that case libraries like the C standard library might change version and anything installed as a port or package may fail to load or work when they haven't been updated yet (this is why you need to reinstall everything after a major version upgrade). There are a few other cases where this could lead to problems, especially when you're working remotely. To prevent any kind of issue simply leave root's shell set to csh(1).
 
For normal users, you probably want to use a more advanced bourne-compatible shell, like shells/zsh or shells/bash.

As far as root’s shell is concerned – that one doesn’t really matter much, because you never use it anyway. Some people even set root’s shell to /usr/bin/nologin for improved security, but it really doesn’t matter much, provided that your root account has a strong password. Never log in as root! Instead, log in as normal user, and then do su -m which gives you your own login shell (the one of your normal user account, not root’s) with added root privileges. Or use one of the various tools for the ports collection for executing tasks that require root privileges: security/super, security/doas or security/sudo.

Note, when you’re booting into single-user mode, init(8) will ask you for the shell to use, the default being /bin/sh. So the shell of the root account is meaningless here, too.

[Edit] PS: The fact that root’s default shell is /bin/csh has purely historic reasons, and it probably won’t change in FreeBSD because of some developers’ irrational feelings attached to BSD’s history. Personally I think that csh / tcsh should be removed from FreeBSD’s base system.
 
That being said, I use regular /bin/sh and I do have command history with the up arrow. No idea why it doesn't work for you.
As long as you don't exit session, of course you have history, but it's on memory. If you exit with Ctrl+D, previous history will not exist. Either that, or your sh is a symlink to another shell that has history.
 
As long as you don't exit session, of course you have history, but it's on memory. If you exit with Ctrl+D, previous history will not exist. Either that, or your sh is a symlink to another shell that has history.
Yes, that's what I have. I didn't think you meant persistent history. In fact that's a thing I always disable on other shells like bash, I don't like my history to be saved to disk (same with web browsers).
 
[Edit] PS: The fact that root’s default shell is /bin/csh has purely historic reasons, and it probably won’t change in FreeBSD because of some developers’ irrational feelings attached to BSD’s history. Personally I think that csh / tcsh should be removed from FreeBSD’s base system.
Out of interest, do you have a source on hand as to why? I have always wondered this myself.

That said, csh is fairly tiny so it certainly doesn't harm things staying around. In some ways it is also a good defense against beginners saying:
FreeBSD only has /bin/sh?!?, we should have more than one choice so I want bash or fish in base!
I would rather csh in there than those fat old things (and I say this as an interactive bash user).
 
Changed my user shell to zsh finally. Quite feature rich, even you can do a full step-by-step config before getting started. Overwhelming for new users.
 
Yes, that's what I have. I didn't think you meant persistent history. In fact that's a thing I always disable on other shells like bash, I don't like my history to be saved to disk (same with web browsers).
Yes I meant persistent history, sorry didn't explain better. Out of curiosity found out, that certain shells like bash, allow to not save commands to history if you start the command with a space. not all systems have it set by default, but can be changed easily:
Code:
bash
export HISTCONTROL=ignorespace
echo '1'
 echo '2'
history | tail -n 2
You will see that echo 2 will not be saved even on current session, you don't have to even close with CTRL+D. Really helpful didn't know that trick :eek:
 
Out of interest, do you have a source on hand as to why [root’s default shell is /bin/csh]? I have always wondered this myself.
i got my first 4 BSD release on 9-track tape in 1983. Root's csh goes back to at least then.

There were a half dozen, or so, accounts installed in /etc/passwd on every BSD system that belonged to the core team.

The release tapes were made so that core team members could work on any system.

In the transition from V6 to V7 Unix, the V6 shell (Ken Thompsons' work) was ditched fast, in favour of the V7 Bourne shell, which had a much better design.

The V6 and V7 Bourne shells had no command history or editing. They were clumsy for interactive use.

Bill Joy had written a few handy things that many Unix users found useful, including csh (vi deserves a mention, as well).

My guess is that it was made the default for everyone, including root, just because the core team preferred it (and especially its interactive features) to the Bell Labs shells of the day.

[The source code for David Korn's shell was available inside Bell Labs by around 1983 or 1984, but not available in any release of Unix until much later.]
 
Good advise. Is it actually practical?

Should it be, "Rarely login as root!"
No, I really mean “never log in as root”. And it is definitely practical. I haven’t logged in as root for the past 25 years. There’s no reason to do that, and good reasons not to.
 
I think that it's pretty well established professional etiquette that logging in as root is a bad thing to do. In work places with well developed security protocols, its almost always forbidden because it breaks the audit trial by providing an anonymous privileged login.

Having said that, at home, its not beyond me to login as root on my notebook or my zfs server to start xdm -- because I don't start xdm by default, and typing "xdm" is all I do. I don't feel any guilt there...

Regardless of whether I might occasionally login as root, or not, I choose to furnish a full login environment for root, with my preferred shell, profile, and aliases, all ready to go in an emergency. The reason is quite simply because the root login is the only one guaranteed to be fully furnished when /usr is not mounted -- and I refuse to struggle with csh (or anything less than my preferred shell) at a time when the integrity of my system is at risk.

I should also say that this approach relates to systems I own personally. I never did this when working in a team environment, where you would would want to see some pretty broad and strong agreement before making such changes.
 
  • Like
Reactions: mer
I think that it's pretty well established professional etiquette that logging in as root is a bad thing to do. In work places with well developed security protocols, its almost always forbidden because it breaks the audit trial by providing an anonymous privileged login.
In fact, it is usually disabled for security reasons, so you cannot log in as root, even if you wanted to.

Having said that, at home, its not beyond me to login as root on my notebook or my zfs server to start xdm -- because I don't start xdm by default, and typing "xdm" is all I do. I don't feel any guilt there...
Actually, that’s a perfect example for using one of security/super, security/doas orsecurity/sudo, instead of logging in as root.

Regardless of whether I might occasionally login as root, or not, I choose to furnish a full login environment for root, with my preferred shell, profile, and aliases, all ready to go in an emergency. The reason is quite simply because the root login is the only one guaranteed to be fully furnished when /usr is not mounted -- and I refuse to struggle with csh (or anything less than my preferred shell) at a time when the integrity of my system is at risk.
When booting into single-user mode, init(8) asks for the shell to run, and /bin/sh is the default. So you don’t have to struggle with csh at all.

Personally I have a habit to keep a statically linked binary of shells/zsh in the /rescue directory, for cases where I have to use single-user mode for more than just a few simple commands. But there were only very few occasions when I actually used it, like two or three times in 25 years.

I should also say that this approach relates to systems I own personally. I never did this when working in a team environment, where you would would want to see some pretty broad and strong agreement before making such changes.
Agreed. Definitely.
 
When booting into single-user mode, init(8) asks for the shell to run, and /bin/sh is the default. So you don’t have to struggle with csh at all.
You have ignored the bit where I said "my preferred shell, profile, and aliases, all ready to go in an emergency".
Sure, I can use /bin/sh, but I choose, and am certainly most comfortable and productive with, a Korn Shell.
That is why I furnish and test these facilities (statically linked ksh, profile, and aliases) every time I build a system.
Logging in as root occasionally to do trivially safe things keeps them tested and working.

You are right that such preparations tend to be rarely used. But it only takes one major incident...
 
  • Like
Reactions: mer
In fact, it is usually disabled for security reasons, so you cannot log in as root, even if you wanted to.
I have never worked in a place where root logins were disabled.
Root passwords were usually kept in a password safe (one place actually had a physical safe), with restricted and audited access.
But if the LDAP servers went down, the root login (which was the only local login) would be your only way in.
And when the LDAP servers were Linux boxes, you can see the Catch 22 we are avoiding...
 
  • Like
Reactions: mer
Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?
 
Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?
I'm not aware of any such documentation, and it would be a false claim anyway.

However, /rescue/ is documented in 3.5 Directory Structure in the FreeBSD Handbook as a directory containing statically linked programs. See the difference for yourself:
Rich (BB code):
$ file /bin/sh /rescue/sh /bin/tcsh /rescue/tcsh
/bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/rescue/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/bin/tcsh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
/rescue/tcsh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 13.0 (1300139), FreeBSD-style, stripped
 
Is there a place in the documentation that says whether non /bin/sh shells in the base system, e.g., /bin/tcsh, are statically linked?
It's also relevant to see where the dynamic dependencies are. i.e.
Code:
[ritz.137] $ ldd /bin/sh /bin/csh /bin/tcsh
/bin/sh:
    libedit.so.7 => /lib/libedit.so.7 (0x800849000)
    libc.so.7 => /lib/libc.so.7 (0x800a83000)
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800e3a000)
/bin/csh:
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800887000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x800ae6000)
    libc.so.7 => /lib/libc.so.7 (0x800d04000)
/bin/tcsh:
    libncursesw.so.8 => /lib/libncursesw.so.8 (0x800887000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x800ae6000)
    libc.so.7 => /lib/libc.so.7 (0x800d04000)
You can see that there's nothing required outside the root for these three shells which are in /bin. So they should be good to go when /usr is not mounted.
However, it's possible to argue that a statically linked shell has fewer dependencies, and possibly more likely to be available in extreme circumstances.
From experience, I know that both ksh and bash have options when compiled and linked from the ports tree for either dynamic or static linking -- but the dynamic linked versions have dependencies in /usr.
Finally, all valid shells (those which are allowed to be appear in /etc/passwd) have their path mentioned in /etc/shells.
 
Back
Top