Open rbdavis opened 2 years ago
<
in args
is not a shell redirection but sets argv[1]
to be <
.
If you want to read from a file, you will want to pass in the file as an argument and read it as a file.
< in args is not a shell redirection but sets argv[1] to be <.
That is indeed what happens, and it's not at all surprising to me. However, I found this suggestion in multiple places on the web offered as a solution to this problem.
If you want to read from a file, you will want to pass in the file as an argument and read it as a file.
Yup, you can certainly do that. However, classic Unix programming often reads by design from stdin and writes to stdout so that programs may be chained together in pipelines. Previous Unix debuggers I have used, e.g., ddd, had a mechanism for connecting an existing file to a program's stdin when debugging it. The absence of this ability within vscode is a serious shortcoming.
Hi I dont' know if there's anyway to bump this thread? I had the same issue as @rbdavis. I'm very non-expert however it does seem from the internet that on linux systems using "args": ["<", "my_file.txt"]
on VSCode does work as desired and for whatever reason it doesn't on a mac :( so it would be nice to have this reconciled.
Thanks!
I never tried this on Linux myself and if it works there I'm glad people using that platform have a way to do this, but I have to agree that the "args": ["<", "my_file.txt"]
thing really is an ugly hack. On all Unix-ish systems including both macOS and Linux, a program in fact never sees '<' in its argv[] list, so it's really ugly to implement this feature in a debugger in this way. Probably there should just be a separate configuration entry like "stdin": "my_file.txt"
.
All of the above notwithstanding, many pieces of Unix software (in particular my own area of scientific applications) read large datasets from stdin, and any truly useful debugger should be able to support this. I used ddd for many years as my debugger, and it had a mechanism for implementing stdin redirection while debugging which worked perfectly well. (ddd no longer runs under macOS or I would not even be using vscode.) The vscode developers for whatever reason don't seem to think this is something worth supporting. They are wrong.
Environment
Bug Summary and Steps to Reproduce
Bug Summary:
I have been unable to find a way to connect large datasets to the stdin of a C code program being debugged by vscode -- it seems possible only to use the launch.json "externalConsole": true setting to input small amounts of manually entered input via an opened terminal window. (Such manual input is entirely unsuited to debugging a program with very large multi-column numerical input datasets.) This problem occurs on both Intel and Apple M1 macOS 12.6 systems.
I have seen recommendations in various places to use a launch.json args setting for this, e.g., "args": ["<", "/tmp/somefile"] , but this simply does not work (other than to corrupt the program's main() argv[] array by appending spurious < and /tmp/somefile arguments, which should obviously not be visible to any program actually reading stdin ). Here is the launch.json entry I tried unsuccessfully to use:
(Note that specifying "externalConsole": true in that configuration only improved the situation to the extent of allowing manually typed input to be sent to stdin , which is not sufficient for my purposes.)
Here is a small sample program which demonstrates the problem. It simply prints out the contents of the main() argv[] array, including the spurious < and /etc/group arguments, and then echoes to stdout whatever is read from stdin :
When run with the above launch.json configuration it hangs indefinitely on the first call to fgets() instead of properly reading the redirected /etc/group through stdin .
I truly hope you can either fix this problem or tell me what I am doing wrong, otherwise vscode is not usable to me for debugging a lot of my project's software which makes heavy use of stdio. Thanks!
Debugger Configurations
Debugger Logs
Other Extensions
No response
Additional Information
No response