[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mksh import
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).
Be still, and know that I am God (Psalms 46:10)
Main Index |
Thread Index |