The original command python line

[Damjan Georgievski]

How can I get the *really* original command line that started my python
interpreter?

Werkzeug has a WSGI server which reloads itself when files are changed
on disk. It uses `args = [sys.executable] + sys.argv` to kind of
recreate the command line, and the uses subprocess.call to run that
command line.

BUT that's problematic as, when you run::

python -m mypackage --config

sys.argv printed in mypackage/__main__.py will be::

['/full/path/to/mypackage/__main__.py', '--config']

so you get::

python /full/path/to/mypackage/__main__.py --config

instead of::

python -m mypackage --config


the difference in the 2 cases is what the current package is, and
whether you can use relative imports.

 

[Chris Rebert]

How can I get the *really* original command line that started my python
interpreter?

Werkzeug has a WSGI server which reloads itself when files are changed
on disk. It uses `args = [sys.executable] + sys.argv` to kind of
recreate the command line, and the uses subprocess.call to run that
command line.

BUT that's problematic as, when you run::

       python -m mypackage --config

sys.argv printed in mypackage/__main__.py will be::

       ['/full/path/to/mypackage/__main__.py', '--config']

so you get::

       python /full/path/to/mypackage/__main__.py --config

instead of::

       python -m mypackage --config


the difference in the 2 cases is what the current package is, and
whether you can use relative imports.

On Linux, you can read from:
/proc/<PID here>/cmdline
to get the null-delimited "command line".

Sidenote: Consensus generally seems to be that relative imports are a bad idea.

Cheers,
Chris

 

[Damjan Georgievski]

How can I get the *really* original command line that started my python

interpreter?

Werkzeug has a WSGI server which reloads itself when files are changed
on disk. It uses `args = [sys.executable] + sys.argv` to kind of
recreate the command line, and the uses subprocess.call to run that
command line.

BUT that's problematic as, when you run::

python -m mypackage --config

sys.argv printed in mypackage/__main__.py will be::

['/full/path/to/mypackage/__main__.py', '--config']

so you get::

python /full/path/to/mypackage/__main__.py --config

instead of::

python -m mypackage --config


the difference in the 2 cases is what the current package is, and
whether you can use relative imports.

BTW, the same thing happens in Python 3.2.2. To reproduce::

mkdir /tmp/X
cd /tmp/X

mkdir mypackage
touch mypackage/__init__.py mypackage/dummy.py

cat <<EOF > mypackage/__main__.py
from __future__ import print_function, absolute_import
import os, sys, subprocess

def rerun():
new_environ = os.environ.copy()
new_environ['TEST_CHILD'] = 'true'
args = [sys.executable] + sys.argv
subprocess.call(args, env=new_environ)

if os.environ.get('TEST_CHILD') != 'true':
Role = 'Parent'
rerun()
else:
Role = 'Child'

try:
from . import dummy
except:
print('Exception in %s' % Role)
else:
print('Success in %s' % Role)
EOF



Both::

python2 -m mypackage

or::

python3 -m mypackage


will print::

Exception in Child
Success in Parent

 

[Chris Rebert]

On Linux, you can read from:
   /proc/<PID here>/cmdline
to get the null-delimited "command line".

After some further searching:
psutil offers `Process.cmdline` cross-platform;
see http://code.google.com/p/psutil/wiki/Documentation

Cheers,
Chris

 

[Damjan Georgievski]

How can I get the *really* original command line that started my python

After some further searching:
psutil offers `Process.cmdline` cross-platform;
see http://code.google.com/p/psutil/wiki/Documentation

Indeed, changing for

args = psutil.Process(os.getpid()).cmdline

in the above example does solve the problem, at least in Linux.

Sidenote: Consensus generally seems to be that relative imports are a

bad idea.

How come?
I'm using explicit relative imports, I thought they were the new thing?

 

[Devin Jeanpierre]

How come?
I'm using explicit relative imports, I thought they were the new thing?

Explicit relative imports are fine. Implicit relative imports can
create multiple module objects for the same source file, which breaks
things like exception handling (because exception types are unequal if
they're from different classes, even if the different classes come
from two executions of the same source code).

-- Devin

 

[Grant Edwards]

On Linux, you can read from:
/proc/<PID here>/cmdline
to get the null-delimited "command line".

And if what you want is your own command line, you can replace <PID
here> with self:

/proc/self/cmdline