Unfortunate dynamic linking for everything

David O'Brien obrien at freebsd.org
Sun Nov 23 14:51:26 PST 2003

> As I pointed out earlier, some of the heat here comes
> from the fact that /bin/sh is currently overloaded:
>  * It is the default system script interpreter, used
>    by the rc scripts and many other things.  As such,
>    it must start quickly.
>  * It is the default user shell for many users.  As such,
>    it must support NSS.
> So far, I haven't seen anyone in this thread seriously
> argue against either of these points.

I'll seriously argue against the 2nd point above.  I don't know of a
SINGLE person that uses /bin/sh as their interactive shell when
multi-user.  Not ONE.  Every Bourne shell'ish user I've ever met uses
Bash, AT&T ksh, pdksh, zsh.

> Richard Coleman wrote:
> >It seems /bin/sh is the real sticking point. 
> There is a problem here: Unix systems have historically used
> /bin/sh for two somewhat contradictory purposes:
>   * the system script interpreter
>   * as a user shell
> The user shell must be dynamically linked in order
> to support centralized administration.  I personally
> see no way around that.  Given that many users do
> rely on /bin/sh, it seems that /bin/sh must be
> dynamically linked.
> There are good reasons to want the system script
> interpreter statically linked.
> Maybe it's time to separate these two functions?

I argue the two functions are already separated as /bin/sh as
interactive shell doesn't really exist outside of single user.

We should build /bin/sh static and be done with the argument.
Or rather, lets find a /bin/sh interactive user and have him argue that
/bin/sh needs NSS support.  I dare say that will be a thread two orders
of magnitude shorter than this one.

-- David  (obrien at FreeBSD.org)

More information about the freebsd-current mailing list