CTRL-C behaviour seems inconsistent in different hosts.

[lucdono77]

Hello,
I have an OSGI based application that uses jline3. I have noticed a different behaviour erasing the line in the console with CTRL-C, with default and without default settings LocalFlag settings.

Linux:

• CTRL-C does not kill the line, but rather exists the application, unless I specify attributes.setLocalFlag(LocalFlag.ISIG, false);
• ^C is always echoed, even though I specify attributes.setLocalFlag(LocalFlag.ECHOCTL, false);

Mac:

• CTRL-C does not kill the line, but rather exists the application, unless I specify attributes.setLocalFlag(LocalFlag.ISIG, false);
• ^C is always echoed, even though I specify attributes.setLocalFlag(LocalFlag.ECHOCTL, false);

Windows:

• CTRL-C does kill without the attributes.setLocalFlag(LocalFlag.ECHOCTL, false);
• ^C is never echoed, even though I specify attributes.setLocalFlag(LocalFlag.ECHOCTL, false);

(On Mac and Linux the instantiated terminals are the same.)

Interestingly, even though the code is the same, when I use my implementation, on the very same host, but from different callers, the behaviour seems different from the one above, for instance, on Linux and Mac the line is properly killed and the ^C char does not appear if I call my implementation from another class. Can multithreading cause a different behaviour of the signals in this latest scenario?

This is an example of my terminal configuration:

public static Terminal createTerminal(LINE_ENDING lineEnding) throws IOException {
        TerminalBuilder builder = TerminalBuilder.builder();
        Terminal terminal = builder.nativeSignals(true).system(true)
                .signalHandler(Terminal.SignalHandler.SIG_DFL).build();
        terminal.enterRawMode();

        Attributes attributes = terminal.getAttributes();
        if (lineEnding != null) {
            attributes.setInputFlag(lineEnding.getFlag(), true);
        }

        // These lines are commented for my experiments
        // attributes.setLocalFlag(LocalFlag.ISIG, false);
        // attributes.setLocalFlag(LocalFlag.ECHOCTL, false);

        terminal.setAttributes(attributes);

       return terminal;
}

This is the fragment that shows how I instantiate the reader with the given terminal:

        reader = LineReaderBuilder.builder().terminal(terminal).build();
        reader.setOpt(Option.MENU_COMPLETE);
        reader.unsetOpt(Option.CASE_INSENSITIVE);

Thanks for your support.
Regards,
Luca

[gnodet]

Looks similar to #938 and #940. Thx for providing detailed informations !

[gnodet]

Actually, I think there's a problem in your config:

• nativeSignals = true means that JLine will use the JVM signal support and replace existing signal handlers
• Terminal.SignalHandler.SIG_DFL means the default JVM behavior

So in your setup, JLine actually does nothing wrt to signal handlers. So you're down to the behaviour of your OS console for both the fact that the application exits or not depending on the local flag, and the echo. If you want JLine to be in control of the INT signal, you need to register a signal handler.

Also not that the different behaviour (based on the "caller") could be caused if you're calling the LineReader or not, as the readline call will actually set a signal handler for the INT signal.

[lucdono77]

Hi, I am trying to build a reproducer for it, but in the meantime I have spotted the following issue with the example provided at https://github.com/jline/jline3/blob/master/builtins/src/test/java/org/jline/example/Example.java (running it via +system).

As you can see from the attached screenshots, on both Mac and Linux (using 3.24.0), I can see the following exception closing the application, if I issue CTRL-C fast: which makes me feel there is some race condition in the LineReaderImpl with the signal handlers, possibly the cause of this ticket.

[gnodet]

@lucdono77 I fixed a threading issue with 0028516#diff-dddd64baa0e1929f2b9e8909cfc545a7b568aaa39d60b16c57a030fed004f0b5R1197

I've also raised a fix with #973 which should fix this very case, which probably only happen with the exec terminal though.

[lucdono77]

Thanks for the info, I have checked and all seems working properly now.