In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Cameron Laird) wrote:
> In article <[EMAIL PROTECTED]>, > Donn Cave <[EMAIL PROTECTED]> wrote: > . > . > . > >Meanwhile, it might be worthwhile to reconsider the use > >of ksh here, if you have any choice in the matter. Ksh > >is fine for interactive use, but has some unfortunate > >flaws as a programming shell, and due to proprietary issues > >one commonly encounters an alternative implementation that's > >even worse. On most modern platforms, sh will have a pretty > >good programming feature set, and will be more reliable > >(especially if it isn't just ksh by another name.) > . > . > . > Infidel. While I sure feel that way about csh(1), it > surprises me you'd criticize ksh(1) so. 'Fact, 'mong > all the *sh-s, I *recommend* ksh for programming. May- > be the two of us see things differently. ----� Portability "ksh" means � -� ksh88 � �(AIX 5.2, ...) � -� ksh93 � �(MacOS X 10.4, ...) � -� pdksh � �(Redhat Linux, NetBSD 2.0, ...) � -� (nothing) (Older BSDs, ...) � Plus, I have seen differences that evidently come from � build options that can be exercised by the platform vendor. � For example, the effect of ksh -p varies, and "echo" seems � to mimic the behavior of sh on its host platform. ----� Reliability Interactive ksh users depend on ENV=$HOME/.kshrc for per-shell transient customization, like aliases, but unlike bash or even csh, this file isn't loaded for an interactive shell startup, but any shell startup.� So if I write a program in ksh, and you run it, my script is exposed to your aliases. ----� Feature over-saturation The Bourne shell is pretty fair for UNIX programming, all things considered, but it's a miserable programming language in a more general context, I mean you can hardly do worse (except, as you mention, csh.)� The Korn shell does nothing to really improve the language, yet it adds myriad features as if catering to some kind of full time ksh programmer.� And that's ksh88, I understand 93 takes it to a whole new level. Modern shells - ash, bash, etc. - implement�a�POSIX/XPG4 shell specification that has plenty of these�features.� That's the obvious target for shell scripts written today. Programs that can't get by with that should probably be written in some other language - Python comes to mind, for example, though I usually try awk first for simplicity of deployment. �� �Donn Cave,[EMAIL PROTECTED]
-- http://mail.python.org/mailman/listinfo/python-list
