Re: mksh import

[Christopher Berardi <cberardi%natoufa.com@localhost>]

For my interactive shell, I'm currently using /bin/ksh. I use it for primarily 
two reasons (neither of which is really earth-shattering). One is because ksh 
allows command tab-completion in addition to filename tab-completion. The other 
is because I can configure $PS1 the way I want to in ksh (with a dynamically 
changing $PWD) and I haven't figured out a way to do that in sh (it will 
usually remain static after the first cd).

But, I don't think one shell is *dramatically* better than another for 
interactive use. It seems the big focus of the debate and this discussion is in 
the area of usability in scripting (what, csh isn't in the running :)).

I'm not sure whether I'm for or against the proposal. I understand what some 
are arguing for with the need for a 'modern' shell that has a powerful feature 
set. I also think there is a need for 'plain vanilla' shell that can be used by 
any hardware that NetBSD can run on (probably didn't word that right).

Here is the criteria I would use to decide. The primary /bin/sh should be:

1) BSD-licensed (should go without saying) or compatible with it

2) should be completely POSIX compliant. Where the POSIX standard is perhaps 
ambiguous, a defined way should be chosen and it should be well documented that 
here are the various ways this <POSIX standard> could be interpreted and here 
is the way this shell is implemented.

3) shouldn't be handcuffed by the POSIX standard. Where there is a compelling 
case to be made for inclusion in feature XYZ that isn't defined in the POSIX 
standard, then it may be included as long as it is well documented that this is 
not in the standard and usage may limit portability (developer beware). 



-- 
Christopher Berardi
http://www.natoufa.com/

Be still, and know that I am God (Psalms 46:10)