On Feb 13, 3:57 am, Anh Hai Trinh <anh.hai.tr...@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
--
http://mail.python.org/mailman/listinfo/python-list
