Issue2623

classification
Title: jython (Linux) does not respect my EOF char
Type: behaviour Severity: normal
Components: Core Versions: Jython 2.7
Milestone: Jython 2.7.0
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: zsd, zyasoft
Priority: Keywords:

Created on 2017-09-04.14:13:49 by zsd, last changed 2017-09-05.18:32:50 by zsd.

Messages
msg11560 (view) Author: Jim (zsd) Date: 2017-09-04.14:13:49
My EOF char is ^Z, not ^D
If I start Python and (eventually) type ^Z at the prompt, it exits, as expected.
If I start Jython and (eventually) type ^Z at the prompt, it is ignored.

This is annoying.
msg11565 (view) Author: Jim Baker (zyasoft) Date: 2017-09-05.16:42:27
I worked on this, and I couldn't find anything better than the solution we discussed in http://bugs.jython.org/issue2276, which is to add the appropriate .inputrc file.

It is possible that we could revisit with the new JLine3, but that requires also an upgrade to Java 8 - intended for Jython 3, but not clear when we will require that for Jython 2.7.
msg11566 (view) Author: Jim Baker (zyasoft) Date: 2017-09-05.16:50:21
Also I was not familiar with remapping of suspend in Linux/OSX, but I did just verify using a [forum answer] that

1) suspend can be remapped via the stty command, eg, stty susp ^V
2) adding an appropriate entry in ~/.inputrc per #2276 will then do the appropriate mapping per Jim's request

[forum answer]: https://superuser.com/a/1032257
msg11567 (view) Author: Jim (zsd) Date: 2017-09-05.16:57:25
Jim,

(1) A sincere thanks for the responses and the work-around, creating that ~/.inputrc does work.  Although I am concerned that some day in the future, some other program will read that file and consequently Do The Wrong Thing.

(2) <boggle> I don't get why an input library would make some arbitrary
decision about what one's EOF character is.  Why not just look at what the user's EOF char is and use that?? </boggle>
msg11568 (view) Author: Jim Baker (zyasoft) Date: 2017-09-05.17:34:18
Agreed, naming it ~/.inputrc seems to be less than ideal for avoiding conflicts with other code, vs say ~/.jline2 or what have you. But JLine2 got us a lot of other benefits.

As for getting the preferred mapping, as I understand it, JLine2 on Linux/OSX does invoke stty as part of its setup of the terminal, so it could presumably get the desired mapping at that time. Clearly it doesn't.

It's possible that JLine3 does the right thing here, or at least it could be modified to do so, given that it is under active development.
msg11569 (view) Author: Jim (zsd) Date: 2017-09-05.18:32:50
I can see the benefits of JLine2.  If only they had thought that one through.
Perhaps filing a bug report with that project is the way to go.

Thanks again for your responses.
History
Date User Action Args
2017-09-05 18:32:50zsdsetmessages: + msg11569
2017-09-05 17:34:18zyasoftsetmessages: + msg11568
2017-09-05 16:57:26zsdsetmessages: + msg11567
2017-09-05 16:50:22zyasoftsetmessages: + msg11566
2017-09-05 16:42:27zyasoftsetnosy: + zyasoft
messages: + msg11565
2017-09-04 14:13:49zsdcreate