vscode: STDIN/STDOUT redirection of debugger doesn't work anymore after 1.67 update
Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.67.0
- OS Version: Windows 10, using
cmd.exeas a default shell
Steps to Reproduce:
When debugging python(I think debuggers of other languages also got effected too), I’m using following launch.json to redirect stdin to my custom input file.
{
"name": "Args from input.txt(Python)",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"cwd": "${fileDirname}",
"args": ["<", "${workspaceFolder}\\input.txt"]
},
This method of implementing redirection when debugging using the < character is also introduced in the official documentation of vscode.
According to the document,
This approach requires that the “<” syntax is passed through the debugger extension and ends up unmodified in the Integrated Terminal.
and it worked like charm before updating to v1.67.0.
From changelog of v1.67, I’ve noticed that there was a fix related to automatically add escape character(^) before special symbols such as < or |
(See 145265 Terminal on Windows uses cmd /C, this corrupts passed arguments)
When I started debugging session, vscode is now really add ^ before <. Since < character is escaped, I cannot used redirection with the method mentioned in the document anymore.
Is this the intended result? If so, how to use redirection ‘correctly’ after this build?
I know a lot of people redirect stdin to input.txt and redirect stdout to output.txt when debugging, which is actually very convenient.
I think that implementing redirection by passing special characters(<, >, |) as arguments of the debugger is not a very graceful solution, but that method itself should not be eliminated.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 7
- Comments: 22 (9 by maintainers)
Commits related to this issue
- launch.json 파일 입출력 리다이렉션 설정 vscode 파이썬 디버그 할 때 표준입출력을 원하는 파일로 연결되도록 설정했습니다. 그런데 어제 vscode 1.67 패치로 정상실행이 안되네요. https://github.com/microsoft/vscode/issues/148887 그래도 편하게 쓰던 기능이라 같이 올립니다. — committed to yeardream-high6/coding_test by ChocoNaga 2 years ago
- Don't escape launch config args that are only '<' and '>'. Fix #148887 — committed to microsoft/vscode by roblourens 2 years ago
- Don't escape launch config args that are only '<' and '>'. Fix #148887 — committed to microsoft/vscode by roblourens 2 years ago
- Don't escape launch config args that are only '<' and '>'. Fix #148887 (#149279) — committed to microsoft/vscode by roblourens 2 years ago
- Don't escape launch config args that are only '<' and '>'. Fix #148887 (#149284) — committed to microsoft/vscode by roblourens 2 years ago
@roblourens just a few comments from vacation…
argsproperties. Some debug extensions introduceargsin their schema contribution but VS Code cannot provide any direct help with redirecting input/output.runInTerminalDAP request which some debug extensions use to implement their (private)argssupport.runInTerminaldoes not allow direct access to shell features (e.g. input/output redirection) because no assumptions can be made about the underlying shell or whether a shell is used at all. So escaping/quoting all shell meta-characters is correct. But we might want to add additional features to therunInTerminalDAP request so that debug adapters can implementstdinFromFile/stdoutToFileproperty support themselves.argsproperty that supports shell features, e.g. acommandLineproperty"commandLine": "arg1 arg2 < input > output". In order to support this we would have to add support to therunInTerminalDAP request to pass a full command line unchanged to the underlying shell.Yeah this is https://github.com/microsoft/vscode/issues/145265. Thanks for pointing out the docs, I didn’t know this was recommended. It’s suspicious to me that we would want to put shell-specific syntax in the args here. That isn’t what “args” means to me.
I wonder whether we could add launch config parameters like “stdinFromFile” and “stdoutToFile” (and add those to the runInTerminal request) so that vscode can come up with the right syntax for the shell. I may want to revert the change until we have a better solution. Thoughts @isidorn @weinand @connor4312? Maybe candidate
I’m not a fan of allowing this. We already try to escape things from those arguments, so people doing this today have only a half-working shell syntax in their arguments. It also only works if you run it in the
integratedTerminal, and is of course shell-dependent too, which feels weird.Thanks. I am going with this solution for the .2 build that will go out next week. Not a perfect fix -
">out.txt"as a single argument would have previously redirected output too - but people are using">"or"<"in all the examples I have seen so far.It will also be in Insiders tomorrow. I noticed another issue with the escaping, https://github.com/microsoft/vscode/issues/149283, which will also get fixed in Insiders
I mean the opposite (the > in
">", "out.txt"would not be escaped, and in"> out.txt"would be escaped)“stdinFromFile/stdoutToFile” makes the most sense to me. I would not be in favor of a
commandLineoption in therunInTerminalrequest since, similar to the initial problem, the DA has no knowledge of the underlying shell.Sorry for the trouble. Like I said, I didn’t realize that people were depending on this behavior, and I agree that it should be supported somehow, since this is a reasonable and useful workflow.
To me, “args” means arguments that get passed to the program you are starting.
I see a couple solutions
argsand require users to shell-escape args in their own config, which is not good, or addescapedArgswhich would be shell-escapedargsand addshellArgsorunescapedArgs, or the more specificstdinFromFile/ stdoutToFileAny of this will require changes to DAP. I wonder whether anyone is trying to use any shell syntax besides >/<, in other words, is there a scenario that adding
stdinFromFile/ stdoutToFilewouldn’t cover?@hw0603 I’ve spent 3 hours trying to come up with a work around. This is insane. So much of my workflow relied on the ability the redirect stdin and stdout using <,>. It’s insane that this was deprecated. I don’t even get why. It doesn’t have to do any crazy checking should just copying what you type in and the shell takes over.
This is a serious issue for me.
@roblourens @connor4312
Yeah I agree that passing redirection symbols through args is somewhat weird, and I understand the need for escaping shell-specific characters. That’s why I’ve said it’s not a graceful solution. However, many people uses the redirection feature through that way now(even if the docs have been mislead the users).
It’s good improvement to escape that characters in arguments since it is literally “argument”, but I think there should be official solution to redirect I/O. As mentioned above, add parameters such as “stdinFromFile” and “stdoutToFile” to launch.json might be best solution.
BTW, what kind of additional information do I have to add here? I think I mentioned all the details of the sitution but I see the “needs more info” label.
Having the same issue with new version in WSL. It seem some characters are prefix with
\. Mylaunch.jsonis"args": ["<", "${fileBasenameNoExtension}_input.txt"]. But in console, the command isfilename.py \< filename_input.txt, due to prefix\, my code is stuck. It was working fine yesterday, So, I think this issue is with new release.