> Rather than disabling, we could initially include the commands and bind > them to /usr/ast/bin only. Users who want the performance and the AST > versions of the commands can opt in by adding /usr/ast/bin to their path. > This makes the AT&T commands easily accessible, without affecting existing > Solaris usage of these commands on ksh.
Yes, that is an excellent idea! I've been using the KSH builtins for some time (several years) and I am not really totally comfortable about having them execute instead of the native binaries as a default situation. Binding them to '/usr/ast/bin' is a great idea since either a user or the system administrator (via '/etc/profile' for example) could put '/usr/ast/bin' before '/usr/bin' in order to get the builtins -- but at least that would be a user or administrator decision rather than being the default. The binaries in '/usr/bin' are too (much too) valuable being stable as they are to not have them as the default. Many things in a typical system will execute '/usr/bin/ksh' in critical cases and the default case should be to use the Sun native binaries rather than the alternative builtins for those binaries. I am a HUGE fan of KSH and have been using it continuously since 1983 (I used it at AT&T Bell Laboratories at the time). I am among those who would like to see KSH be put into the system as '/usr/bin/ksh'. It has been quite stable for some time and any more significant bugs that might be more user visible are generally rapidly fixed by the AST folks. I've had terrible problems with bugs in the Solaris native KSH in the past and in my experience, the AST version would not be worse (likely much better). Just my two cents on the issue. :-) Dave Morano morano at computer.org
