PEP 787 – Safer subprocess usage using t-strings
- Author:
- Nick Humrich <nick at humrich.us>, Alyssa Coghlan <ncoghlan at gmail.com>
- Discussions-To:
- Discourse thread
- Status:
- Draft
- Type:
- Standards Track
- Requires:
- 750
- Created:
- 13-Apr-2025
- Python-Version:
- 3.15
- Post-History:
- 14-Apr-2025
Abstract
PEP 750 introduced template strings (t-strings) as a generalization of f-strings,
providing a way to safely handle string interpolation in various contexts. This PEP
proposes extending the subprocess
and shlex
modules to natively support t-strings, enabling
safer and more ergonomic shell command execution with interpolated values, as well as
serving as a reference implementation for the t-string feature to improve API ergonomics.
Motivation
Despite the safety benefits and flexibility that template strings offer in PEP 750, they lack a concrete consumer implementation in the standard library that demonstrates their practical application. One of the most compelling use cases for t-strings is safer shell command execution, as noted in the withdrawn PEP 501:
# Unsafe with f-strings:
os.system(f"echo {message_from_user}")
# Also unsafe with f-strings
subprocess.run(f"echo {message_from_user}", shell=True)
# Fails with f-strings
subprocess.run(f"echo {message_from_user}")
# Safe with t-strings and POSIX-compliant shell quoting:
subprocess.run(t"echo {message_from_user}", shell=True)
# Safe on all platforms with t-strings:
subprocess.run(t"echo {message_from_user}")
# Safe on all platforms without t-strings:
subprocess.run(["echo", str(message_from_user)])
Currently, developers must choose between convenience (using f-strings with potential
security risks) and safety (using more verbose, list-based APIs). By adding native t-string
support to the subprocess
module, we provide a consumer reference implementation that
demonstrates the value of t-strings while addressing a common security concern.
Rationale
The subprocess module is an ideal candidate for t-string support for several reasons:
- Command injection vulnerabilities in shell commands are a well-known security risk.
- The
subprocess
module already supports both string and list-based command specifications. - There’s a natural mapping between t-strings and proper shell escaping that provides both convenience and safety.
- It serves as a practical showcase for t-strings that developers can immediately understand and appreciate.
By extending subprocess to handle t-strings natively, we make it easier to write secure code without sacrificing the convenience that led many developers to use potentially unsafe f-strings.
Specification
This PEP proposes two main additions to the standard library:
- A new
sh()
renderer function in theshlex
module for safe shell command construction - Adding t-string support to the
subprocess
module’s core functions, - particularly
subprocess.Popen
,subprocess.run()
, and other related functions that accept a command argument
- Adding t-string support to the
Renderer for shell escaping added to shlex
As a reference implementation, a renderer for safe POSIX shell escaping will be added to
the shlex
module. This renderer would be called sh
and would be equivalent to
calling shlex.quote
on each field value in the template literal.
Thus:
os.system(shlex.sh(t"cat {myfile}"))
would have the same behavior as:
os.system("cat " + shlex.quote(myfile)))
The addition of shlex.sh
will NOT change the existing admonishments in the
subprocess
documentation that passing shell=True
is best avoided, nor the
reference from the os.system()
documentation to the higher level subprocess
APIs.
The t-string processor implementation would look like:
from string.templatelib import Template, Interpolation
def sh(template: Template) -> str:
parts: list[str] = []
for item in template:
if isinstance(item, Interpolation):
# shlex.sh implementation, so shlex.quote can be used directly
parts.append(quote(str(item.value)))
else:
parts.append(item)
# shlex.sh implementation, so `join` references shlex.join
return join(parts)
This allows for explicit escaping of t-strings for shell usage:
import shlex
# Safe POSIX-compliant shell command construction
command = shlex.sh(t"cat {filename}")
os.system(command)
Changes to subprocess module
With the additional renderer in the shlex module, and the addition of template strings,
the subprocess
module can be changed to handle accepting template strings
as an additional input type to Popen
, as it already accepts a sequence, or a string,
with different behavior for each. In return, all subprocess.Popen
higher level
functions such as subprocess.run()
could accept strings in a safe way
(on all systems for shell=False
and on POSIX systems for shell=True
).
For example:
subprocess.run(t"cat {myfile}", shell=True)
would automatically use the shlex.sh
renderer provided in this PEP. Therefore, using
shlex
inside a subprocess.run
call like so:
subprocess.run(shlex.sh(t"cat {myfile}"), shell=True)
would be redundant, as run
would automatically render any template literals
through shlex.sh
When subprocess.Popen
is called without shell=True
, t-string support would still
provide subprocess with a more ergonomic syntax. For example:
subprocess.run(t"cat {myfile} --flag {value}")
would be equivalent to:
subprocess.run(["cat", myfile, "--flag", value])
or, more accurately:
subprocess.run(shlex.split(f"cat {shlex.quote(myfile)} --flag {shlex.quote(value)}"))
It would do this by first using the shlex.sh
renderer, as above, then using
shlex.split
on the result.
The implementation inside subprocess.Popen._execute_child
would check for t-strings:
from string.templatelib import Template
if isinstance(args, Template):
import shlex
if shell:
args = shlex.sh(args)
else:
args = shlex.split(shlex.sh(args))
Backwards Compatibility
This change is fully backwards compatible as it only adds new functionality without altering existing behavior. The subprocess module will continue to handle strings and lists in the same way it currently does.
Security Implications
This PEP is explicitly designed to improve security by providing a safer alternative to using f-strings with shell commands. By automatically applying appropriate escaping based on context (shell or non-shell), it helps prevent command injection vulnerabilities.
However, it’s worth noting that when shell=True
is used, the safety is limited to
POSIX-compliant shells. On Windows systems where cmd.exe or PowerShell may be used as the shell,
the escaping mechanism provided by shlex.quote()
is not sufficient to prevent all forms
of command injection.
How to Teach This
This feature can be taught as a natural extension of t-strings that demonstrates their practical value:
- Introduce the problem of command injection and why f-strings are dangerous with shell commands
- Show the traditional solutions (list-based commands, manual escaping)
- Introduce the
shlex.sh
renderer for explicit shell escaping:# Unsafe: os.system(f"cat {filename}") # Potential command injection! # Safe using shlex.sh: os.system(shlex.sh(t"cat {filename}")) # Explicitly escaping for shell
- Introduce the subprocess module’s native t-string support:
# Unsafe: subprocess.run(f"cat {filename}", shell=True) # Potential command injection! # Safe but verbose: subprocess.run(["cat", filename]) # Safe and readable with t-strings: subprocess.run(t"cat {filename}", shell=True) # Automatically escapes filename subprocess.run(t"cat {filename}") # Automatically converts to list form
The implementation should be added to both the shlex and subprocess module documentation with clear examples and security advisories.
Deferring escaped rendering support for non-POSIX shells
shlex.quote()
works by classifying the regex character set [\w@%+=:,./-]
to be
safe, deeming all other characters to be unsafe, and hence requiring quoting of the string
containing them. The quoting mechanism used is then specific to the way that string quoting
works in POSIX shells, so it cannot be trusted when running a shell that doesn’t follow
POSIX shell string quoting rules.
For example, running subprocess.run(f"echo {shlex.quote(sys.argv[1])}", shell=True)
is
safe when using a shell that follows POSIX quoting rules:
$ cat > run_quoted.py
import sys, shlex, subprocess
subprocess.run(f"echo {shlex.quote(sys.argv[1])}", shell=True)
$ python3 run_quoted.py pwd
pwd
$ python3 run_quoted.py '; pwd'
; pwd
$ python3 run_quoted.py "'pwd'"
'pwd'
but remains unsafe when running a shell from Python invokes cmd.exe
(or Powershell):
S:\> echo import sys, shlex, subprocess > run_quoted.py
S:\> echo subprocess.run(f"echo {shlex.quote(sys.argv[1])}", shell=True) >> run_quoted.py
S:\> type run_quoted.py
import sys, shlex, subprocess
subprocess.run(f"echo {shlex.quote(sys.argv[1])}", shell=True)
S:\> python3 run_quoted.py "echo OK"
'echo OK'
S:\> python3 run_quoted.py "'& echo Oh no!"
''"'"'
Oh no!'
Resolving this standard library limitation is beyond the scope of this PEP.
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
Source: https://github.com/python/peps/blob/main/peps/pep-0787.rst
Last modified: 2025-04-19 07:54:03 GMT