This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jgehrcke
Recipients docs@python, georg.brandl, jgehrcke, pitrou, vstinner
Date 2015-02-09.21:09:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za>
In-reply-to
Content
When Python is invoked with the `-c command` switch, the command string does not get exposed in sys.argv:

    $ python -c "import sys; print(sys.argv)"
    ['-c']

    $ python -c "import sys; print(sys.argv)" arg1
    ['-c', 'arg1']

The command string does not get exposed anywhere, AFAIK, so it is inaccessible from within Python programs. There might be application scenarios in which it is useful to access the command string, such as for debugging purposes. One scenario is when a Python session should be able to "re-spawn" itself in a subprocess (I came across this question on StackOverflow: http://stackoverflow.com/q/28412903/145400)

I propose to make the command string accessible. If you agree that it might make sense, the question is *how/where* to expose it.

One possible way is to retain it in sys.argv, as in this example:

    $ python -c "import sys; print(sys.argv)" "arg1"
    ['-c', 'import sys; print(sys.argv)', 'arg1']

The current sys.argv docs say 

> If the command was executed using the -c command line option to
> the interpreter, argv[0] is set to the string '-c'.

This sentence could then be adjusted to 

"[...], argv[0] is set to the string '-c', and argv[1] contains the command."

This method breaks existing applications that are started with the -c method and that consume command line arguments in a sys.argv[1:] fashion. The tests in Lib/test/test_cmd_line.py all pass, however.

A second method would be to change sys.argv[0] from '-c' to '-c command'. This would break existing applications that check for sys.argv[0] == 'c'.

A third method would be to leave sys.argv as it is, and expose the command with a new attribute in the sys module.

I have attached a patch for variant 1 (passes all tests in Lib/test/test_cmd_line.py), to demonstrate which code is affected: the translation from the "real" argv to sys' argv is triggered in Modules/main.c. The patch does not change behavior of '-m' (it's funny, however, that the current version of main.c at first replaces the module string with '-m', whereas the runpy module later on replaces '-m' with the path to the module file anyway.).

As a side node, I figure that the sys.argv documentation should be adjusted to properly reflect the -m behavior, which is:

    $ ./python -m testmodule foo
    testmodule sys.argv: ['/data/local/pythondev/pythontip/cpython/testmodule.py', 'foo']

Let me hear your comments, and I am willing to work on code and doc patches, thanks!
History
Date User Action Args
2015-02-09 21:09:28jgehrckesetrecipients: + jgehrcke, georg.brandl, pitrou, vstinner, docs@python
2015-02-09 21:09:28jgehrckesetmessageid: <1423516168.08.0.69949754755.issue23427@psf.upfronthosting.co.za>
2015-02-09 21:09:28jgehrckelinkissue23427 messages
2015-02-09 21:09:27jgehrckecreate