On 16-06-14 13:09, Chris Angelico wrote:
> On Mon, Jun 16, 2014 at 8:51 PM, Tim Chase
> <python.l...@tim.thechases.com> wrote:
>> On 2014-06-16 20:41, Chris Angelico wrote:
>>> Oops! I made the cardinal error of trying in one and assuming it'd
>>> work in both. Just needs a b prefix on the split string:
>>> def shell_split(cmd):
>>> return subprocess.check_output("""python -c 'import sys;
>>> You'll get back a list of byte strings, in any case. Feel free to
>>> pass them through a decode operation, or to incorporate a .decode()
>>> into the above stream, as you wish.
>> Tested on Win32? The behavior of "shell expansion" on Windows
>> cmd.exe differs from most *nix shells (i.e., it *doesn't* expand, so
>> you have to do it yourself), so Antoon would need to describe the
>> desired behavior on Win32.
> Well, his example commands began "ls", which is a common Unix command,
> but isn't present on most Windows systems. If he'd started out with
> something that looked more Windowsish, I'd totally understand - you
> start with a single line, and you need to do what the cmd.exe shell
> hasn't done for you. (Although splitting is done, so it still wouldn't
> be quite as clear.) But he said "treated as a command line". So that's
> exactly what I did. :) He didn't ask about globbing, he asked about
> doing what the shell does... maybe he wants variable expansion too?
That would be interresting too. The problem with your solution would be
that it would only substitute environment variables, and not "shell variables"
within the interactive session. Of course I could use os.putenv to put all
those variables in the environment but that might have troublesome effects
on other subprocesses.