Re: Unfortunate dynamic linking for everything

From: David O'Brien <obrien_at_freebsd.org>
Date: Sun, 23 Nov 2003 14:51:18 -0800
> 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)
Received on Sun Nov 23 2003 - 13:51:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC