shells management

D

dalpets

I have only a newcomers appreciation of optimum management practices of shells.
A Google search says that it can be a dangerous practice to change the default shell (csh/sh), that may cause potential system login problems? To forestall that happening in my early entry into fbsd my questions are, in what circumstances would it be necessary to change the root default shell or the user shell?
 
It's best to leave the root shell to sh.
You can add a user toor with another shell with also root permissions.
As regular you can use any shell. I use zsh , but many use fish.
 
As a user, are there clear advantages of using one shell over another or is it a matter of 'horses for courses'?
This is probably like long standing historical arguments about why one top selling brand of vehicle is perceived to be superior to another. People have their allegiances, sometimes for, perhaps, hard to appreciate or murky reasons -:)
 
You should always have one superuser account (typically root) with a shell from base, so either /bin/sh or /bin/csh. This makes sure you can always log in to fix a potential problem with ports/packages.

FreeBSD comes with a second superuser account (same uid 0) named toor which you can activate just by setting a password for it. If you want a superuser account with a shell from ports, it's common practice to use toor for that. It would of course work as well the other way around, giving toor a shell from base and root one from ports.
 
Zirias said:
You should always have one superuser account (typically [cmd]root) with a shell from base, so either /bin/sh or /bin/csh. This makes sure you can always log in to fix a potential problem with ports/packages. [/cmd]

FreeBSD comes with a second superuser account (same uid 0) named toor which you can activate just by setting a password for it. I
Click to expand...
How/where do i set the password?
 
Except when you build/install WITHOUT_TCSH=yes, then the default becomes /bin/sh ;)

But the important thing is: use a shell from base.
 
dalpets said:
How/where do i set the password?
Click to expand...
Log in as a superuser (root by default). Say "passwd toor", or in general passwd for the account you want to set the password of. You will be prompted for the password.

I use bash on all machines. Not claiming that it is the best choice, only that I got accustomed to it.
 
ralphbsz said:
Log in as a superuser (root by default). Say "passwd toor", or in general passwd for the account you want to set the password of. You will be prompted for the password.

I use bash on all machines. Not claiming that it is the best choice, only that I got accustomed to it.
Click to expand...
Ok done that, thanks. How do I now get into/see the toor superuser shell?
 
Let me pour you some tea, pass the crumpets, and tell you about the time I decided to change the root shell on a Sun Ultra 60 to bash.

It was my first week at $LARGE_FAMOUS_SOFTWARE_COMPANY, and I could barely stand my own coolness. Full of youth and arrogance, and blissfully unaware of the depths of my own ignorance, I figured all the bleating about statically linked shells was nonsense. Besides, bash was so much freaking cooler than the lame old sh Sun was saddling me with. Also, real men logged in as root all the time because they never make mistakes.

So I downloaded and installed bash from Sunsite, vipw'd away, and of course decided to reboot the box because I was a Windows fool. It promptly refused to boot with a cryptic error message. The flip side of a large ego is that it is very fragile, and mine is no exception. I was too embarrassed to ask my colleagues or IT for help, so I embarked on a sweaty 11-hour misadventure to resolve the problem.

Sun machines of that era (and maybe later, I don't know) mounted a very minimal root filesystem with a small set of key binaries which included sh. That sh (probably Bourne, but I don't remember) was statically linked, and therefore completely self contained. The boot process would then execute a series of shell scripts to mount the other filesystems and do other initialization. I had been smart enough to move bash into the root filesystem, but not smart enough to find the libraries it dynamically loaded using ldd(1). Had I done that, I would've discovered bash needed a bunch of files that were off in some other filesystem (probably /usr/local, I don't remember). The boot process would mount root, try to execute root's shell, and explode in midair when bash refused to run.

Careful partitioning of hard disks to prevent system downtime caused by full filesystems is somewhat of an anachronism nowadays. Heck, there are some that want to put everything in one big filesystem. It's the modern way. The point is, make sure you know exactly what you're doing before you try changing root's shell.
 
SirDice said:
Root's shell is csh(1) by default.
Click to expand...
Yes, but there are some details one can run into. FreeBSD Quickstart Guide for Linux® Users (albeit from 2008), states:
Instead, FreeBSD uses tcsh(1) as the default root shell, and the Bourne shell-compatible sh(1) as the default user shell.
Click to expand...

My own 12.xR experiences ( ps -p $$)*: root shell is csh(1); normal user shell is tcsh(1). However, when entering commands that should differentiate between csh and tcsh, it left me with an enigma. That is, until I started hunting down the origins: ls -l csh tcsh

This gave me the definitive answer:
Code: 
% ls -i1 -l /bin/csh /bin/tcsh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8 02:13 /bin/csh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8 02:13 /bin/tcsh
I don't know at which FreeBSD version this was included and if it is considered more or less permanent, but some hint in the handbook or in the man pages would have been informative. On the plus side: I learned a few extra commands ;)

If I have overlooked this csh-tcsh "non-existant dichotomy" in the documentation, I'd appreciate a pointer to the clarification.

* I found this helpfull: How to test what shell I'm using in terminal?
 
csh(1) and tcsh(1) are the exact same executable and file. They're simply hardlinked. Depending on its invocation it enables a certain feature set.

Root's shell has been set to csh(1) since I started using FreeBSD some 20+ years ago with 3.0. And csh(1) has been root's shell before that. Ever since the first versions.

Releng/1 source code: https://cgit.freebsd.org/src/tree/bin/csh?h=releng/1
Some time during 4.x csh was upgraded to tcsh: https://cgit.freebsd.org/src/commit...4&id=733a48bba4413497567cbb63e1202ed6e5c46169

Tcsh is an improved C shell, just as bash is an improved Bourne shell. Bash can be invoked as sh(1) and will not enable those new features and run in a 'compatibility' mode. On a lot of Linux distributions (not all of them do this) /bin/bash and /bin/sh are hardlinked (i.e. they refer to the same file). The same thing happens with tcsh, if invoked as csh it will run in a compatibility mode. The same hardlinking on /bin/csh and /bin/tcsh is done (that's why the inodes are the same).

What I don't understand is why people keep thinking root's shell is sh(1). Probably because all system scripts are written in sh(1). But those two things have nothing to do with each other.
 
Well, that's a pretty nice story :cool: – but:
Jose said:
The boot process would mount root, try to execute root's shell, and explode in midair when bash refused to run.
Click to expand...
this sounds like a pretty broken design. Why should anything ever during a boot process try to execute root's configured shell? I'f you're sure you remember this incident correctly, Sun f*cked up ;)

edit: except of course if this:
Jose said:
I had been smart enough to move bash into the root filesystem
Click to expand...
means you replaced the system shell with bash … o_O

Anyways, the risks with using a shell that isn't part of the base system aren't gone as soon as you use one big fs (or one big zpool with all datasets mounted early on). They are smaller, but still, it's more likely to mess up /usr/local than to mess up your base system.
 
You must log in or register to reply here.
Back
Top