root /etc/csh

[perryh at pluto.rain.com]

> > > > ... Why doesn't FreeBSD ship bash and other shells besides
> > > > the `sh' linked statically is beyond me. It wouldn't break
> > > > ports, would it?
> > > 
> > > It does break ports.  Very, very badly.  I know because I've
> > > personally attempted replacing /bin/sh with bash as a "I have
> > > a weekend to spare" project.
> > 
> > You misunderstand. I do not suggest replacing the standard shell
> > with bash, I suggest that the shells available in FreeBSD, even
> > through ports to be linked statically so they can be used for
> > rescue and recovery.  If the default make instructions told to
> > compile statically, it wouldn't break the ports.
>
> You're right -- I'm still not understanding.  So let me cover the
> bases here:
>
> 1) The entire ports and FreeBSD build system (see: world) rely
> heavily on /bin/sh-isms and do not work with bash.  bash being
> compiled statically will not solve these problems.

If this is accurate, it should be reported to the bash maintainers as
a bug.  Bash claims complete Posix compatibility (plus extensions).
In any event, it is irrelevant to the OP's point.

> 2) Changing the root users' shell is not recommended.  There are
> a lot of reasons for this, but as mentioned, the main one is
> single-user scenarios (where /usr hasn't been mounted yet, thus
> /usr/local/bin/bash is not available -- and if it's installed as
> /bin/bash, the libraries /bin/bash link to are not available).

This, of course, being the whole point of the OP's suggestion to
link port shells statically.

> 3) You can build bash statically; make WITH_STATIC_BASH=true.  I do
> not know the true reason why the port is not built statically by
> default, but I can give you a damn good reason why it shouldn't be:
> complete and total wasted memory.
>
> Take into consideration environments where there are hundreds (or at
> my place of work, thousands) of users logged into a machine at once.
> Many of those are going to have /usr/local/bin/bash as their shell.
> A statically-linked version of bash would waste significant amounts
> of memory, while a dynamically-linked/shared version would ease that
> pain.  The same applies for any static vs. dynamic program.

How so?  Wouldn't a single in-memory instance of the bash text
segment be shared among all bash processes, across all users?
Granted, there is, in effect, *one* extra instance of the part
of libc that gets linked into the static bash.

A better reason is that security updates to shared libs often
update only the .so files, expecting the binaries that use them
to automatically pick up the new versions.  Any static executable
should be rebuilt any time there is a security update to a shared
lib that it would be using were it linked dynamically.

That said, perhaps it would be reasonable for shell ports to
build both a dynamically-linked instance to be installed in
/usr/local/bin, and a statically-linked instance to be installed
in, say, /usr/local/static.  Those who want to use bash as the
root shell could copy it from there to /bin or /sbin.