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