Ksh-ish functionality on Unix systems

[Quinn Dunkan]

On 21 Sep 2001 00:18:59 GMT, Donn Cave <donn at u.washington.edu> wrote:
>Quoth weeks at vitus.scs.agilent.com (Greg Weeks):
>| The low-level support is far too verbose for casual use.  The higher-level
>| stuff seems incomplete.  However, the higher-level stuff becomes a lot more
>| complete if the command arguments are passed to, say, /bin/sh on Unix
>| systems.  In that case, os.system and getstatusoutput capture the above Ksh
>| functionality, and os.popen and popen2.* are bonuses.
>|
>| So: Is it a reasonable approach as a Unix user to rely on the fact that the
>| os.system and getstatusoutput commands are passed to a shell?
>|
>| Or is that tacky?  If that *is* tacky, is there a *convenient* alternative?
>
>system() and getstatusoutput() will indeed invoke the shell, that's
>a given.  What's tacky about that is a multiple evaluation problem,
>when you construct the shell command out of input data from some not
>entirely predictable source.  When the shell evaluates its command line,
>results are lowered to another, unpleasant dimension of unpredictability.

Another possibility is to use a more sane shell, like rc.  The problem with sh
(and ksh too, I'm sure) is that their "parsing" is so complicated no one
really wants to figure out exactly how they work except Evil Hackers.  rc has
much simpler quoting rules.

If there were a high level plumbing module for python, one possibility is that
it would implement a little language that would look something like a
simplified more regualr version of sh.  rc is already reasonably close to
this.

Or you could turn around and try a set of pure python plumbing classes that
wrap up all the nasty pipe() and fork()iness; it sounds like a fun project.