Dan Christian added the comment:
I haven't been following this much. Sorry. My day job isn't in this area any
more (and I'm stuck using 2.4 :-().
Looking at the docs, I notice the "old" is different from what it used to be.
Notably: 'e;' gets split
Dan Christian added the comment:
> Sure :) That’s why I suggest using dash for quick tests and rely on the work
> of other people who did read the POSIX spec. I’ll have to check it too
> before committing a patch.
The point of ref_shlex.py is that all shells act the same for com
Dan Christian added the comment:
On Sat, Nov 26, 2011 at 7:12 AM, Éric Araujo wrote:
> Your script passes with dash, which is probably the most POSIX-compliant
> shell we can find. (bash has extensions, zsh/csh don’t use the POSIX shell
> language, so I think the behavior of dash
Dan Christian added the comment:
I just realized that I left out a major case. The shell will also
split (). I think this is now complete. If you do "man bash" and
skip down to DEFINITONS it lists all the control characters.
I've attached updated versions of ref_shlex.py and
Dan Christian added the comment:
I've attached a diff to test_shlex.py and a script that I used to
verify what the shells actually do.
Both are relative to Python-3.2.2/Lib/test
I'm completely ignoring the quotes issue for now. That should
probably be an enhancement. I don't
Dan Christian added the comment:
Of course, that's how it's used. That's all it can do right now.
I was was splitting and combining commands (using ;, &&, and ||) and
then running the resulting (mega) one liners over ssh. It still gets
run by a shell, but I was specify
Dan Christian added the comment:
It's been a while since I looked at this. I'm not really in a
position to contribute code/tests right now; but I can comment.
I don't think POSIX mode existed when I first reported this, but
that's where it makes sense. I think all PO