No love for Python's shlex.quote[1] or their equivalents in other languages to quote arguments for shell? In his case, which is interpolating a variable inside a shell double-quoted string, I would probably use environment variables, or else use shell `printf` with `shlex.quote`. But generally I interpolate directly into the command line using `shlex.quote`, when I can't avoid executing using the shell.<p>I was happy to learn about Python's template string proposal (i.e., t-strings) from <a href="https://peps.python.org/pep-0750/" rel="nofollow">https://peps.python.org/pep-0750/</a>, although it probably won't become common for a while.<p>[1] <a href="https://docs.python.org/3/library/shlex.html#shlex.quote" rel="nofollow">https://docs.python.org/3/library/shlex.html#shlex.quote</a>
Pipeline in Python w/o invoking the shell:<p><pre><code> username = input("Hello, what's your name? ")
p1 = Popen(["figlet", f"Welcome, {username}"], stdout=PIPE)
p2 = Popen(["lolcat", "-f"], stdin=p1.stdout, stdout=PIPE)
p1.stdout.close() # Allow p1 to receive a SIGPIPE if p2 exits.
banner = p2.communicate()[0]
print(banner)
</code></pre>
<a href="https://docs.python.org/3/library/subprocess.html#replacing-shell-pipeline" rel="nofollow">https://docs.python.org/3/library/subprocess.html#replacing-...</a><p>Don't use the shell unless you absolutely have to, and when you do have to, use shlex.quote for quoting arguments:<p><a href="https://docs.python.org/3/library/shlex.html#shlex.quote" rel="nofollow">https://docs.python.org/3/library/shlex.html#shlex.quote</a><p><pre><code> username = input("Hello, what's your name? ")
banner = check_output(f"figlet "Welcome, {quote(username)}" | lolcat -f", shell=True)
print(banner)
</code></pre>
For something this simple, you could also just use `subprocess.check_output` twice:<p><pre><code> username = input("Hello, what's your name? ")
banner = check_output(["figlet", f"Welcome, {username}"])
banner = check_output(["lolcat", "-f"], input=banner)
print(banner)</code></pre>
This is one reason why, really, nobody should use a shell that was optimized for commandline use, for scripting.<p>On the commandline, all your inputs are usually known and trusted, so the shell language will take a few shortcuts to make everything more convenient for the user. But of course, when scripting, these assumptions don't hold and you need a language with more notational rigor.<p>Bash et al. are dangerous scripting languages, and they become even more dangerous when users (who typically don't want to understand the subtleties) start using LLMs to generate code for them.