1

I did a little utility "sa.py" for myself that works from command line. It calls FFMPEG to do the real work. This sa.py accepts some options: 

#! /usr/bin/env python3
# ...
import argparse
# ...
parser = argparse.ArgumentParser(description='...')
parser.add_argument(
    '--track',
    default='10m',
    dest='track',
    help="..."
)
# ...
args = parser.parse_args()

If I run ./sa.py by itself it works fine (it sees correctly all command line options passed). The troubles starts when I tried to develop a python GUI that launch ./sa.py as a subprocess. The gui launches the subprocess, and the sa.py is correctly executed as a subprocess, but this time the command-line are somewhat ignored, even if specified. The default values (example "10m" for "--track" option) will be always used regardless the fact you specified a different value.

I remark: ./sa.py itself can process correctly its own command line But ./sa.py will not see the command line options when it is runned as a subprocess of the "GUI" python script

so the problem is focused on the usage of subprocess.call inside sa_gui.pyw, but I can't guess where the problem is:

# this piece of code is included in a class on a python script
# that uses tk gui
# self.track, self.delta etc are all tkinter.StringVar() variables
# that you could change on the proper tkinter.Entry "widget"
cmd = [ os.path.realpath('./sa.py'),
        '--track', self.track.get(),
        '--delta', self.delta.get(),
        '--min', self.minimal.get(),
        '--balance', self.balance.get()]
# ...
subprocess.call(cmd, shell=True)

If I debug "cmd" values, it contains all the infos desired:

  • (correct) location of ./sa.py script to launch
  • --track
  • [track_value]
  • --delta
  • [delta_value]

...and so on.

So I cannot figure where the problem is and why the command line options are ignored by ./sa.py when subprocessed buy ./sa_gui.pyw

Any help?

Searches:

Not useful: The question is related to how to subprocess python script and the python version actually used. Here the problem is focused on argparse used by subrprocessed python script

Not useful: I'm not asking here how to capture output from subprocess

Not useful: For the same reason as (2)

Community
  • 1
  • 1
Nobun
  • 141
  • 1
  • 1
  • 10

1 Answers1

1

Solution

I can reproduce your problem on OSX with:

subprocess.call(cmd, shell=True)

It works without shell=True:

subprocess.call(cmd)

Test Code

sa.py:

#! /usr/bin/env python3

import argparse
import sys


parser = argparse.ArgumentParser(description='...')
parser.add_argument(
    '--track',
    default='10m',
    dest='track',
    help="..."
)
args = parser.parse_args()
print(args)
print(sys.argv)

call_sa.py:

import os
import subprocess

cmd = [os.path.realpath('./sa.py'), '--track', '12']

print('shell False')
subprocess.call(cmd)
print()
print('shell True')
subprocess.call(cmd, shell=True)

Output:

python call_sa.py 
shell False
Namespace(track='12')
['/Users/mike/tmp/sa.py', '--track', '12']

shell True
Namespace(track='10m')
['/Users/mike/tmp/sa.py']
Community
  • 1
  • 1
Mike Müller
  • 82,630
  • 20
  • 166
  • 161
  • This work also under linux. Unluckly this not properly work on windows (I tested on a virtual machine legally provided by microsoft itself). So I am afraid it is not possible to subprocess correctly in a multi-platform way. Under windows, infact, the argparse will be however ignored (both if you set shell=True and shell=False... if you use shell=False you need to add sys.executable to the subprocess command list). I'm afraid that the only solution is to launch the child script importing it in the GUI script instead of subprocessing. I hoped I could use subprocess, however. :/ – Nobun Jan 18 '16 at 11:56