On Thu, Jul 07, 2005 at 10:17:56PM -0500, Tao Chen wrote: > I vote for changing the default shell to a better one.
Ah, but then the question is, which one. You might choose ksh over bash for various reasons, others might prefer tcsh, and some of us know that zsh is the One True Shell. If nothing else, the bourne shell is one we can all agree isn't something we want to use for very long. ;-) At any rate, you or anyone else is free to design your own distribution of OpenSolaris that has whatever you like lurking behind /bin/sh, or to change all the places in the codebase that essentially make /bin/sh the default shell. You may need to deal with some incompatibilities when it comes to scripts, but you can fix those up as necessary, either in the shell or in the scripts. It's your distribution, do as you please. Now, if you want the change to be made in Sun Solaris, there's a higher bar. Like Shawn and Rich have said, we care very deeply about incompatibilities introduced by any change to the system, and we have a fairly complex risk management (not risk avoidance, mind) process built up around this. I don't know how ready we are for external contributors to participate in the ARCs, so keep in mind that for the time being, the following is somewhat hypothetical. You'd need to propose the exact nature of the change: - are you changing the actualy interpreter that /bin/sh is? - are you modifying /bin/sh to include a handful of useful features? - are you changing root's default shell? - are you changing everyone's default shell? - something else? You'd need to demonstrate that the changes violate no standards: - what standards govern /bin/sh on a Solaris system? - do those standards have testsuites? You'd need to demonstrate that the changes don't break anything: - full system test - test suites - performance regressions And you'd need to be prepared for Sun not to accept the risk of the change, regardless of the technical arguments. /bin/sh is such a core part of the system, and changing it is such a sweeping change, that it might just be considered too risky, period. Then again, Sun accepted -- in fact was quite excited by -- the changes that SMF introduced. So sweeping changes are possible. The rigor to which you'd be subjected also depends on the nature of the change. I think that changing what /bin/sh is would likely be the hardest sell (though it would be interesting to run a system with bash as /bin/sh through our test suites). You'd much more likely get traction on one of the less invasive changes. For instance, you could suggest adding commandline editing to the shell. I'm not sure what standards govern /bin/sh, but not POSIX (that's /usr/xpg4/bin/sh, as someone pointed out). Maybe SVID? Don, are you here? Anyway I don't think adding features strictly for interactive use is likely to break any compatibilities. Again, consulting a standards guru would be my first course of action here. But any change that isn't going to touch the command interpreter is going to have less unmeasurable risk. Changing the default shell -- either globally, or for root, or for everyone but root -- would probably be simpler (though the arguments that raged over changing root's home directory might lead you to believe otherwise). However, there are such good workarounds -- custom jumpstart scripts, in particular -- that it still might be a hard sell. I think you might find from the hoarier unix crowd that the general feeling is, if you know enough to use a shell, you know enough to change it (or find out how), and if you don't know enough to change it, you're probably living in a GUI world. Now, I know that's a generalization, but hey -- I'm pretty sure that chsh was on my first unix cheatsheet. And I do know plenty of people who continue using /bin/sh and just don't know any better. At any rate, the way to go about it is write up the proposal -- what you plan to do, what risks are involved, what the benefits are, and so forth. Sun would have to do some business-side evaluation, but it's a valid project, even if it gets rejected in the end. My own personal feeling on it, FWIW, is that it's a problem to be solved at installation (something you should already be able to do with jumpstart, as I mentioned before). But even for an interactive install, say that we had an installer that could be told (or recognize) that you were installing a machine for your own personal use. It could then be a bit more verbose in the questions it asks, allowing you to customize the system a bit more, maybe choosing some more user-friendly defaults than for a machine that's going to be a server sitting in a dark hole somewhere. Of course, any such project would have to wait until the Install side of the house gets open-sourced, or you write your own from scratch. And it's just a thought on how to solve the original problem. Anyway, I hope that provides some real meat to chew on -- if you actually want to make this change, be prepared for very vigorous debate and possibly rejection, but I wouldn't consider it impossible. Danek _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
