-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On Windows, JLine 3.4.0 interferes with the std input of sub process. #169
Comments
Could you check if the following code works better ?
|
So, I've updated the imports: and lines before calling the runCommand with:
|
Hi, I made another test where the properties are saved just after creating the terminal:
and restoring those attributes before calling the runCommand
|
Yes, I misread the problem.
|
Hi, Thanks for your help. I guess you mean terminal.close() before runCommand() and then do a terminal builder.build () at each loop ? See the code below and the result => same problem... We loose also the history at each loop ? We made quite complex tab completion and quite long to initiate (using command grammar, etc...). So, this 'workaround' is not really suitable. Perhaps this problem is linked with #140 (but not only because closing the terminal (i.e. the workaround) should work and it is not the case). My understanding is that the library is doing some initializations on the STDIN (for Windows) that changes the standard behavior and the sub process inherits those and be stuck (when typing a 'enter' key it goes to the begin of the line instead of accepting the new entry line). Any other idea ?
after the timeout, back to the application and the new terminal creates is a dumb terminal... |
Could you enable debug logging (using java.util.logging) and find out why the terminal can't be recreated ? It might give some useful information... |
Voilà... Enabling the log in the first example... Indeed, some useful information (;o):
|
Is that the full log ? I'm looking for the |
OK. Recreate the previous case:
/Users/Phil/Downloads/image-5.png |
Could you build jline with the following patch 4166615 and see if it works better ? |
The exception should not be a problem anymore now that we use the |
As requested, JLine library rebuilt with the code provided in the branch specified for the patch 4166615. So, indeed the ouput stream seems ok in the subprocess and the terminal can be rebuilt at each loop. However, Jline is still interfering with the STDIN with the sub-process (and the terminal is closed !). So, the problem is not solved. |
and the log:
|
I've just tried the following code.
I've tried it with jansi and latest jline and it's working without any problems for me when running a simple batch file containing |
It works fine with the echo test for me too (;o). Stdout is ok for the subprocess however it is not the case for the stdin. Have you try to re-launch your small java test application (a second time) from it ? |
Could you verify that the following commit gnodet@f8eda07 fixes your issue ? |
Hi, Due to time constraint, I was not able to test the latest version of your library but if it includes a mechanism to save the input console mode (from the start of the application) to be restore when calling the subprocess and reverse (meaning to restore the input console mode when back from the process execution with the value saved before execution), I guess part of the issue will be solved. I've integrate a patch like explained in the previous paragraph to our application but in some cases, the subprocess was still frozen and sometime part of the password characters typing in the subprocess is appearing in clear in the main application using jline. This bug is not acceptable... Further to my investigation in the library, I made a test where I remove the NonBlockingReader with a classical reader, This reader calls the 'process event' from the queue of STDIN. Foloowing some tests done so far, it seems, for the functionality that I need for my application are affected by this bloking readng, and the application + jline without the windows 'pump thread' seem to work better - windows is already managing an input buffer per porcess for us... I give you some copy of codes about this test done. I would to know if a parameter can be defined somewhere to start jline in a 'single reading' thread. This will certainly help resolving the issue #140 also. ` This class wraps a regular reader and allows it to appear as if it
|
@gnodet Sorry to spam a closed issue, but can this be relevant? https://stackoverflow.com/a/377154/4496364 So, instead of these: https://github.com/jline/jline3/blob/master/terminal-jna/src/main/java/org/jline/terminal/impl/jna/win/JnaWinSysTerminal.java#L28-L29 it would be something like |
@sake92 Not sure this is related to this issue. This would be more about getting the correct handle if the input or output is redirected, right ? But I agree, this would seem a better solution in case of a redirect. Feel free to raise a new JIRA, but we need to investigate the exact behavior wanted and find a solution for osx / linux. |
Trying to use the JLine as library for a console launching OS or perl scripts, we found the following problem on Windows: Below the source code of small application, launching a subprocess from the input of JLine readline. When trying to execute a small perl script (see below), from the small application, the std input is blocked (see the image included). Calling this small application (from this small application) is also blocking. So, it is not a perl problem (;o).
Tests made on Windows 7 and Windows 2016 server.
Perl Script:
The text was updated successfully, but these errors were encountered: