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 specifying the control flow. 0

 It's kind of like a makefile command block.  You want to be able to
specify if a failure aborts the sequence, or is ignored (&& vs ;).
Sometimes there are fallback commands (via ||).  Of course, you can
also group using ().

Once things are split properly, then understanding the shell control
characters is straight forward.  I my mind, shlex.split() should
either be as close to shell syntax as possible, or have a clear
explanation of what is different (and why).

I ended up doing my own parsing.  I'm not actually at that company
anymore, so I can't pull up the code.

I'll see if I can come up with a reference case and maybe a unittest
this weekend (that's really the only time I'll have to dig into it).

-Dan

On Thu, Nov 24, 2011 at 9:20 AM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> Thanks for the comments.
>
>> There are really two cases in one bug.
>> The first part is that the shell will split tokens at characters that shlex doesn't.  The handling
>> of &, |, ;, >, and < could be done by adjusting the definition of shlex.wordchars.  The shell may
>> also understands things like: &&, ||, |&, and >&.  The exact definition of these depends on the
>> shell, so maybe it's best to just split them out as separate tokens and let the user figure out the
>> compound meanings.
> Yes.  I think that the main use of shlex is really to parse a line into chunks with a way to embed spaces; it’s intended to parse a program command line (“prog --blah "value stillthesamevalue" "arg samearg"”), but not necessarily a full shell line (with & and | and whatnot).  When people have a line containing & and |, then they need a shell to execute it, so they would not call shlex.split but just pass the full line to os.system or subprocess.Popen.  Do you remember what use cases you had when you opened this report?
>
>> The proper handling of quotes/escapes requires some kind of new interface.  You need to distinguish
>> between tokens that were modified by the quote/escape rules and those that were not.
> I don’t see why I would care about quotes in the result of shlex.split.
>
> See also #7611.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1521950>
> _______________________________________
>