Bug description
On Windows, a python -c "..." (or similar -c/-e inline-code) command with nested quotes inside the code string can fail with a Python-side syntax error that indicates cmd.exe's quote parsing corrupted the argument before Python ever saw it.
Reproduction (observed in the wild)
A command shaped like:
py -c "import py_compile; py_compile.compile('pinokio_compat.py', doraise=True); print('OK')"
failed with:
File "<string>", line 1
"import
^
SyntaxError: unterminated string literal (detected at line 1)
Note the Python source string Python actually received starts with a literal " character — meaning cmd.exe's argument parsing did not consume the outer double quotes the way a POSIX shell would for -c "..." containing inner single-quoted strings, parens, and commas.
Why this isn't fixed yet
Unlike the head/grep/pager issues already fixed in #412/#414 (a simple "this command/utility doesn't exist on cmd.exe" pattern match), this is a genuine quoting/escaping mismatch between how a model writes a -c invocation (assuming bash-style quote nesting) and how cmd.exe's argument parser actually behaves. A reliable pre-flight detector for "this quoting will get mangled by cmd.exe" is a much harder, higher-false-positive-risk problem than a simple command-name pattern match, so it needs more careful design (or possibly better tool-description guidance telling the model to avoid inline -c/-e code with nested quotes on Windows, in favor of writing a temp script file and running that) rather than a quick heuristic.
Suggested directions (not evaluated in depth)
- Tool-description guidance: on Windows, recommend writing inline code to a temp
.py/.js file (via write_file) and running that, instead of -c/-e with complex nested quoting.
- Or: have the bash tool itself detect
-c/-e flags on known REPL launchers with quote characters inside the payload and warn pre-flight.
Bug description
On Windows, a
python -c "..."(or similar-c/-einline-code) command with nested quotes inside the code string can fail with a Python-side syntax error that indicates cmd.exe's quote parsing corrupted the argument before Python ever saw it.Reproduction (observed in the wild)
A command shaped like:
failed with:
Note the Python source string Python actually received starts with a literal
"character — meaning cmd.exe's argument parsing did not consume the outer double quotes the way a POSIX shell would for-c "..."containing inner single-quoted strings, parens, and commas.Why this isn't fixed yet
Unlike the
head/grep/pager issues already fixed in #412/#414 (a simple "this command/utility doesn't exist on cmd.exe" pattern match), this is a genuine quoting/escaping mismatch between how a model writes a-cinvocation (assuming bash-style quote nesting) and how cmd.exe's argument parser actually behaves. A reliable pre-flight detector for "this quoting will get mangled by cmd.exe" is a much harder, higher-false-positive-risk problem than a simple command-name pattern match, so it needs more careful design (or possibly better tool-description guidance telling the model to avoid inline-c/-ecode with nested quotes on Windows, in favor of writing a temp script file and running that) rather than a quick heuristic.Suggested directions (not evaluated in depth)
.py/.jsfile (via write_file) and running that, instead of-c/-ewith complex nested quoting.-c/-eflags on known REPL launchers with quote characters inside the payload and warn pre-flight.