> 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