ANN: Sarge, a library wrapping the subprocess module, has been released.

Vinay Sajip vinay_sajip at yahoo.co.uk
Mon Feb 13 11:34:02 CET 2012


On Feb 13, 3:57 am, Anh Hai Trinh <anh.hai.tr... at gmail.com> wrote:

>
> I don't disagree with it. But the solution is really easy, just call 'sh' and pass it a string!
>
> >>> from extproc import sh
> >>> n = int(sh(“ls /etc –1 | wc –l”))
>
> No parser needed written!
>
> Yes there is a danger of argument parsing and globs and all that. But people are aware of it. With string parsing, ambiguity is always there. Even when you have a BNF grammar, people easily make mistakes.

You're missing a few points:

* The parser is *already* written, so there's no point worrying about
saving any effort.
* Your solution is to pass shell=True, which as you point out, can
lead to shell injection problems. To say "people are aware of it" is
glossing over it a bit - how come you don't say that when it comes to
locking+forking? ;-)
* I'm aiming to offer cross-platform functionality across Windows and
Posix. Your approach will require a lower common denominator, since
the Windows shell (cmd.exe) is not as flexible as Bash. For example -
no "echo foo; echo bar"; no "a && b" or "a || b" - these are not
supported by cmd.exe.
* Your comment about people making mistakes applies just as much if
someone passes a string with a Bash syntax error, to Bash, via your
sh() function. After all, Bash contains a parser, too. For instance:

>>> from extproc import sh
>>> sh('ls >>> abc')
/bin/sh: Syntax error: redirection unexpected
''

If you're saying there might be bugs in the parser, that's something
else - I'll address those as and when they turn up.

Regards,

Vinay Sajip



More information about the Python-list mailing list