FAQ
Python 2.6/Windows: shlex.split() does not support unicode
strings. Is this simply a limitation of the current shlex
implementation or is this an intentional design decision that
reflects the behavior of how the Windows shell supports unicode
values?

Specifically, it doesn't appear that subprocess.Popen() has any
restrictions on unicode args, but perhaps I'm missing some edge
cases where this may be true?

If this is simply a limitation of the current shlex
implementation, does anyone see any risks to encoding a command
string using 'xmlreplace' ( command.encode( 'utf8', 'xmlreplace'
) ) in order to hide unicode chars, splitting the now ASCII
string using shlex.split, and then walking the list of strings
returned by shlex.split, decoding them back to Unicode ( .decode(
'utf8' ) ) before passing this list to subprocess.Popen() for
execution?

Thanks,
Malcolm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100830/46a5532a/attachment.html>

Search Discussions

  • Chris Rebert at Aug 30, 2010 at 2:04 pm

    On Mon, Aug 30, 2010 at 6:54 AM, wrote:
    Python 2.6/Windows: shlex.split() does not support unicode strings. Is this
    simply a limitation of the current shlex implementation or is this an
    intentional design decision that reflects the behavior of how the Windows
    shell supports unicode values?
    It's a bug: http://bugs.python.org/issue1170

    Also, shlex is cross-platform; the limitation has nothing to do with
    Windows. As a matter of fact, the docs mention how shlex's
    functionality is based off of Unix and POSIX.

    Cheers,
    Chris
    --
    Kudos for avoiding shell=True
    http://blog.rebertia.com
  • Python at Aug 30, 2010 at 2:24 pm
    Hi Chris,
    Thanks for pointing out the shlex bug. My concern was that shlex had
    Windows specific Unicode limitations because of the way the Windows
    shell so poorly supports unicode output.
    Kudos for avoiding shell=True
    My understanding is that the only time one needs to use shell=True is
    when they are 'executing' a non-executable file whose executable must be
    discovered via file association rules? Does that sound accurate?

    Malcolm
  • Tim Golden at Aug 30, 2010 at 5:45 pm

    On 30/08/2010 3:24 PM, python at bdurham.com wrote:
    My understanding is that the only time one needs to use shell=True is
    when they are 'executing' a non-executable file whose executable must be
    discovered via file association rules? Does that sound accurate?
    I'm not entirely sure what you mean by that last piece. Certainly, shell
    must be used if you're trying to run, eg, dir or copy which aren't executables
    in their own right but are sub-executables [a word I've just invented] of
    the command processor (cmd.exe). There's a slightly open question as to
    whether you need to say shell=True when running batch files (.bat/.cmd).
    My experience is not; others say yes.

    The ".... must be discovered via file association rules" looks out
    of place in your explanation above. (read: I can't see what you're
    getting at :) )

    TJG
  • Nobody at Aug 30, 2010 at 7:25 pm

    On Mon, 30 Aug 2010 10:24:26 -0400, python wrote:

    Kudos for avoiding shell=True
    My understanding is that the only time one needs to use shell=True is
    when they are 'executing' a non-executable file whose executable must be
    discovered via file association rules? Does that sound accurate?
    You also need to use it to execute commands which are built into the shell
    rather than being separate executables.

    On Windows, whether "shell" is True or False and whether "args" is a
    string or list are orthogonal. If args is a list, it will be converted to
    a string using the same rules regardless of whether the shell is used.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 30, '10 at 1:54p
activeAug 30, '10 at 7:25p
posts5
users4
websitepython.org

People

Translate

site design / logo © 2022 Grokbase