calling ksh script from python

[Donn Cave]

In article <obp3n2-dqu.ln1 at lairds.us>, claird at lairds.us (Cameron Laird) 
wrote:

> In article <donn-A60B27.09045802062005 at gnus01.u.washington.edu>,
> Donn Cave  <donn at u.washington.edu> 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, donn at u.washington.edu