Prevent inherited input stream from being closed on Windows (fixes #1115) #1213
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gnodet
force-pushed
the
fix-issue-1115
branch
2 times, most recently
from
92bb9c4 to
5462f7a
Compare
gnodet
changed the title
gnodet
changed the title
This commit implements a workaround to fix the issue with interruption handling in nested shells. The fix clears the current pipe before creating a child shell and restores it afterward, ensuring that when Ctrl+C is pressed in a child shell (e.g., when running 'sh' followed by 'ttop'), the interruption signal is properly propagated to the child process. The implementation uses reflection to access the Pipe.setCurrentPipe method in Felix Gogo runtime, which is currently private. The proper fix has been submitted to the Felix project in two PRs: 1. apache/felix-dev#411 - Make Pipe.setCurrentPipe public 2. apache/felix-dev#412 - Update Posix.runShell to handle nested shells Once these PRs are merged and released, the modified Shell.java and Posix.java classes should be removed from JLine and the official Felix Gogo JLine implementation should be used instead. Fixes #1143
#1115) The problem occurs because ProcessBuilder.inheritIO() causes the subprocess to inherit all standard streams (stdin, stdout, stderr) from the parent process. When the subprocess terminates, it closes these streams, which can cause issues if the parent process still needs to use them. This fix modifies the isPosixSystemStream and systemStreamName methods in ExecTerminalProvider to handle Windows differently: 1. For isPosixSystemStream: - On Windows: - For SystemStream.Output and SystemStream.Error, we use explicit redirects to avoid inheriting stdin - For SystemStream.Input, we use isWindowsSystemStream which is safer on Windows - On non-Windows platforms, we continue to use inheritIO() as it works fine there 2. For systemStreamName: - On Windows, for SystemStream.Input, we use System.console() to check if stdin is a terminal without using ProcessBuilder - For all other cases, we use the original approach This approach is targeted and minimally invasive, focusing only on fixing the Windows-specific issue while leaving the behavior unchanged for other platforms.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes issue #1115 where the inherited input stream is closed when a subprocess terminates on Windows.
The problem occurs because
ProcessBuilder.inheritIO()causes the subprocess to inherit all standard streams (stdin, stdout, stderr) from the parent process. When the subprocess terminates, it closes these streams, which can cause issues if the parent process still needs to use them.This fix modifies the
isPosixSystemStreamandsystemStreamNamemethods inExecTerminalProviderto handle Windows differently:For
isPosixSystemStream:isWindowsSystemStreamwhich is safer on WindowsinheritIO()as it works fine thereFor
systemStreamName:System.console()to check if stdin is a terminal without using ProcessBuilderThis approach is targeted and minimally invasive, focusing only on fixing the Windows-specific issue while leaving the behavior unchanged for other platforms.