classification
Title: Add sys.orig_argv: original command line arguments passed to the Python executable
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: docs@python, georg.brandl, jgehrcke, jwilk, krivushinme, pitrou, r.david.murray, vstinner, zach.ware
Priority: normal Keywords: patch

Created on 2015-02-09 21:09 by jgehrcke, last changed 2020-06-29 22:53 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
sys_argv_cmd.patch jgehrcke, 2015-02-09 21:09
Pull Requests
URL Status Linked Edit
PR 20729 merged vstinner, 2020-06-08 17:08
Messages (15)
msg235633 - (view) Author: Dr. Jan-Philip Gehrcke (jgehrcke) * Date: 2015-02-09 21:09
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!
msg235645 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-02-09 23:09
sys.argv must not be changed. It would break too many Python applications.

*If* we decide to expose the command line parameter in Python, we can
add a new variable like sys.command for example. "command" name in
used in the C code of Python, and also comes from "c" of "-c".
msg235677 - (view) Author: Mihail Krivushin (krivushinme) Date: 2015-02-10 09:58
Hello, I have find some workaround to get actual argv, but it broken:

python -c 'import ctypes; argv = ctypes.POINTER(ctypes.c_char_p)(); argc = ctypes.c_int(); ctypes.pythonapi.Py_GetArgcArgv(ctypes.byref(argc), ctypes.byref(argv)); print([argv[i] for i in xrange(0, argc.value)])'

And this will output:
['python', '-c', '-c']

May be we just need to fix this behaviour, due this is error, as far as i can see. But may broke something.
msg235680 - (view) Author: Dr. Jan-Philip Gehrcke (jgehrcke) * Date: 2015-02-10 11:25
Victor,

I support the idea of sys.command. However, it would be unpopulated most of the time (e.g. set to None by default). Now, is that something we should push forward or not? I would work on a patch, but we should have an agreement first, I guess.


Mihail,

the original argv becomes modified in the very early bootstrap phase, and the command gets lost within that process: it gets *overwritten* with "-c", which is exactly why you are observing two "-c". This happens here:

https://hg.python.org/cpython/file/default/Modules/main.c#l684

So, no, without a code change in main.c there will be no way to retain the command for later usage.
msg235681 - (view) Author: Mihail Krivushin (krivushinme) Date: 2015-02-10 11:30
Jan-Philip, yes, I see that Main.c needs modification, but we can fix orig_argv with not just assignment but with full copy. So then we can get unmodified argv.
msg235705 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2015-02-10 20:59
Rather than add a variable to sys that will be empty 99% of the time, I think I'd rather stick a '__command__' constant in the __main__ module namespace when running with '-c' (think of '__file__').  You could then get at it elsewhere with 'from __main__ import __command__' (probably wrapped in a try/except ImportError, since it will usually not exist).

This should probably be discussed on python-ideas.

(Removing all versions but 3.5, as this is a feature request.)
msg371017 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 16:57
I marked bpo-29857 as a duplicate of  this issue.
msg371022 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 17:13
See also bpo-14208 "No way to recover original argv with python -m". For the specific case of `python -m`, the original argument has been available as `__main__.__spec__.name` since Python 3.4.
msg371025 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 17:17
Many names have been proposed:

* sys.__argv__: https://bugs.python.org/issue14208#msg155002
* sys.argv_original: https://bugs.python.org/issue14208#msg155053
* sys.full_argv or sys.executable_argv: https://bugs.python.org/issue14208#msg155102
* sys.executable_argv: https://bugs.python.org/issue29857 (issue title)
* sys._executable_argv: https://bugs.python.org/issue29857#msg289938
* sys._configuration.raw_argv: https://bugs.python.org/issue14208#msg179845
* sys.raw_argv: https://bugs.python.org/issue14208#msg179852
* sys.raw_args: https://bugs.python.org/issue29857#msg289933
* sys._raw_argv: https://bugs.python.org/issue29857#msg289873
* sys.orig_arv: https://bugs.python.org/issue29857#msg289936

I chose "sys.orig_argv" attribute name with the documentation:

   The list of the original command line arguments passed
   to the Python executable.
msg371027 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 17:19
I marked bpo-15577 "Real argc and argv in embedded interpreter" as duplicate of this issue: my PR 20729 allows embedders to set PyConfig.orig_argv which becomes sys.orig_argv.
msg371028 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 17:25
Example of sys.orig_argv usage to re-execute the Python process with different options:
---
import sys
import os
if not sys.flags.utf8_mode:
    # Force UTF-8 mode
    argv = sys.orig_argv.copy()
    argv[1:1] = ["-X", "utf8"]
    print(f"Re-execute to force UTF-8 mode! argv={argv}")
    os.execv(argv[0], argv)

print(f"Everybody loves UTF-8! utf8_mode={sys.flags.utf8_mode}")
---

Example coming from discussions on the PEP 597 :-)

Output:
---
$ ./python force_utf8_mode.py 
Re-execute to force UTF-8 mode! argv=['./python', '-X', 'utf8', 'force_utf8_mode.py']
Everybody loves UTF-8! utf8_mode=1
---
msg371031 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-08 17:31
My implementation (PR 20729) is based on bpo-40910 change which added a private PyConfig._orig_argv member to fix Py_GetArgcArgv().
msg372157 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-23 10:57
The setproctitle project uses Py_GetArgcArgv() and would benefit of PyConfig.orig_argv, see:

* https://bugs.python.org/issue15577#msg370965
* https://github.com/dvarrazzo/py-setproctitle/issues/8
msg372639 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-29 22:49
New changeset dd8a93e23b5c4f9290e1cea6183d97eb9b5e61c0 by Victor Stinner in branch 'master':
bpo-23427: Add sys.orig_argv attribute (GH-20729)
https://github.com/python/cpython/commit/dd8a93e23b5c4f9290e1cea6183d97eb9b5e61c0
msg372640 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-06-29 22:53
I added sys.orig_argv to the master branch (future Python 3.10).
History
Date User Action Args
2020-06-29 22:53:45vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg372640

stage: patch review -> resolved
2020-06-29 22:49:11vstinnersetmessages: + msg372639
2020-06-23 10:57:41vstinnersetmessages: + msg372157
2020-06-16 21:19:38vstinnersetversions: + Python 3.10, - Python 3.5
2020-06-08 17:32:12vstinnersettitle: Python should expose command when invoked with -c -> Add sys.orig_argv: original command line arguments passed to the Python executable
2020-06-08 17:31:21vstinnersetmessages: + msg371031
2020-06-08 17:25:18vstinnersetmessages: + msg371028
2020-06-08 17:19:00vstinnersetmessages: + msg371027
2020-06-08 17:18:11vstinnerlinkissue15577 superseder
2020-06-08 17:17:29vstinnersetmessages: + msg371025
2020-06-08 17:13:40vstinnersetmessages: + msg371022
2020-06-08 17:12:38jwilksetnosy: + jwilk
2020-06-08 17:08:11vstinnersetstage: patch review
pull_requests: + pull_request19940
2020-06-08 16:57:35vstinnersetmessages: + msg371017
2020-06-08 16:57:23vstinnerlinkissue29857 superseder
2015-02-18 06:06:51r.david.murraysetnosy: + r.david.murray
2015-02-10 20:59:27zach.waresetversions: - Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6
nosy: + zach.ware

messages: + msg235705

assignee: docs@python ->
components: - Documentation
2015-02-10 14:51:26krivushinmesetversions: + Python 2.7, Python 3.2, Python 3.3, Python 3.4
2015-02-10 11:30:46krivushinmesetmessages: + msg235681
2015-02-10 11:25:44jgehrckesetmessages: + msg235680
2015-02-10 09:58:44krivushinmesetnosy: + krivushinme
messages: + msg235677
2015-02-09 23:09:07vstinnersetmessages: + msg235645
2015-02-09 21:09:28jgehrckecreate