Shell – Why is the default shell in Debian 7 bash

There is no need at all for you to use the default shell for a given system. Both Debian and FreeBSD provide a number of different shells, and most or all of them are available on both, either preinstalled or easily installable.

Watch out for naming. It's not uncommon for /bin/csh to really be tcsh, or for /bin/sh to be bash or ksh.

sh, the Bourne shell, is the oldest Unix shell that's still in common use. bash is probably the most widely used sh derivative; ksh and zsh are also widespread.

csh, the C shell, was developed for BSD by Bill Joy. It has some features that make for more convenient interactive use than sh (or at least than the old version of sh that existed at the time). tcsh is derived from csh, and adds a lot of new features, most of them aimed at interactive use. As you've seen by reading csh.whynot, csh and tcsh have some problems when it comes to using them for scripting as opposed to interactively.

Personally, I started with csh, then switched to tcsh when it became available. I now rarely use csh for scripting, preferring sh or bash (or Perl for anything reasonably complex).

(Update, a few years later: I've since abandoned tcsh, and I now use bash interactively.)

My advice would be to pick a single shell and learn it well, using it on both FreeBSD and Debian. If you choose tcsh, I think you'll have to install it on Debian: sudo apt-get install tcsh. If you choose bash, I don't know whether it's preinstalled on FreeBSD; if it isn't, it should be equally straightforward to install it.

It's not necessary to use the same shell interactively and for scripting, but it can avoid some confusion and make for a shorter learning curve.

ksh is probably about as powerful as bash, and zsh is even more powerful (and has a lot of features I've never taken the time to learn).

I suggest bash, for both FreeBSD and Debian (and for any other Unix-like systems you might use), and for both interactive use and scripting. But other choices are perfectly legitimate, and some might suit you better.

When a child process is created with clone with the CLONE_NEWNS flag, the child process gets its own mount namespace. Mounting operations (mount, umount, mount --bind, etc.) in the child namespace only have an effect inside that namespace, and mount operations in the parent namespace only have an effect outside the new namespace.

Except, that is, for shared mounts. A mount can be shared, in which case operations affect all the namespaces that the mount is shared in. A typical use case for shared mounts is to make removable drives available in child namespaces such as chroots. There are more types of relationships (private mounts, unbindable mounts); for more details, see the kernel documentation.

You can check whether a mount is shared by checking /proc/PID/mountinfo: if the line contains shared:NUMBER then the mount is shared, and the number is a unique value identifying the set of namespaces that it's shared between. If the line contains no such indication, the mount is private.

On your system, /proc is shared. When you mount a new instance of proc in the child namespace, since you're mounting over the parent's /proc, that new instance is also shared, so it's visible in both the child namespace and the parent namespace. When you exit the child namespace, the second instance of /proc remains mounted, since it's shared with the still-active parent namespace.

Two things complicate your scenario: you're also creating a PID namespace, and you're using /proc both as the subject of the experiment and as a means of observation. When ps complains about /proc not being mounted, it's actually displaying a misleading error message — the wrong proc is mounted (a proc for the wrong namespace). You can observe this with ls /proc and cat /proc/1/mountinfo. I recommend doing the experiments with a scratch filesystem, it would be easier to understand what was going on.

parent# ./a.out
child# echo $$
2
child# ls /proc
This is the parent's proc, with /proc/PID in the parent PID namespace
child# ps 1
… init
child# mount -t proc proc /proc
Now /proc in the child mount namespace is for the child PID namespace
child# ps 1
… a.out
child# exit
parent#

So far it didn't matter whether /proc was private or shared, but now it does. If /proc is private, then at this point we're observing the parent's /proc, which was never affected and shows the PID namespace. But if /proc is shared, then the mount command we issued earlier affected both namespaces, thus:

parent# ls /proc
acpi asound buddyinfo …
parent# ps 1
Error, do this: mount -t proc proc /proc
Actually, /proc is mounted, but it's the proc for the PID namespace that we created earlier and now has zero running processes.
parent# grep -c ' /proc ' /proc/mounts
2
parent# umount /proc
We've unmounted the child PID namespace's /proc that was shadowing the parent namespace's /proc, so the “normal” /proc is visible again.
parent# ps 1
… init