Repository navigation
Allow a launch to override the standard input file of its launch configuration #3027
Description
Use case
I write small C and Java programs that read their input from stdin, and I debug them over and over with the same input. Today there are two ways to supply it:
- type or paste it into the console on every run, or
- set Common > Input File in the launch configuration, separately for every configuration. A new program needs a new configuration and its own setup before the first run which is tedious process since there are no keyboard shortcuts for that.
Other IDEs make this a one-time setting. In VS Code, for example, a single launch configuration with an input file applies to whatever program is started - be it a python script or a C program.
I built a plugin with a toolbar toggle. When it is on, every Run and Debug launch reads its standard input from one chosen file. It works with CDT (run, and debug with GDB) and with Java launches. It feeds the file through the process's IStreamsProxy and closes the input for EOF.
It has one gap a plugin cannot close: when a launch configuration has its own Input File, ProcessConsole feeds that file as well, and the two inputs get mixed. ProcessConsole reads IDebugUIConstants.ATTR_CAPTURE_STDIN_FILE only from the launch configuration, so nothing outside the configuration can change which file a launch reads.
Proposal
Let the launch override the configuration. ProcessConsole would first look for ATTR_CAPTURE_STDIN_FILE among the attributes of the process's ILaunch, and use the launch configuration's attribute only if the launch has none:
String stdinFile = process.getLaunch().getAttribute(IDebugUIConstants.ATTR_CAPTURE_STDIN_FILE);
if (stdinFile == null && configuration != null) {
stdinFile = configuration.getAttribute(IDebugUIConstants.ATTR_CAPTURE_STDIN_FILE, (String) null);
}A plugin sets the attribute in ILaunchListener.launchAdded, which runs before the launch delegate creates any process. Everything else already exists:
- resolving variables in the file name,
- the "file not found" message,
- EOF after the file (Send EOF to process when its stdin input file is fully read #2969),
- a new console for every process the launch gets later, for example after a restart of a CDT debug session.
The plugin would then only set the attribute. It would no longer write to process streams or touch launch configurations.
This adds no new API type. The javadoc of ATTR_CAPTURE_STDIN_FILE would say that it may also be set on the launch, and that the launch's value wins.
The same could be done for ATTR_CAPTURE_IN_FILE (output file) for symmetry, but I have no use case for that.
Alternative
A more general variant is a contributed input provider: an extension point or service returning the InputStream for a process, so input could also come from somewhere other than a file. That needs new API, plus a priority order when several providers claim the same process. The launch attribute covers
the file case with much less, and a provider could still be added later.
Limitation
Without a ProcessConsole (Common > Allocate console off), no input is fed, neither from the configuration nor from the launch. That is unchanged.
A prototype with tests in ProcessConsoleTests is on my fork: https://github.com/anydoby/eclipse.platform/tree/launch-stdin-override. I'll open it as a PR if this direction is acceptable
Here's how my plugin looks like today (I only have it locally, not shared with the community yet, but if this feature is accepted I can also share the plugin since it will be much more usable).

Activity