The LinePipedInputStream breaks the terminal character buffer

[gnodet]

As expained in the LineDisciplineTerminal,

 * In order to correctly handle line discipline, the console
 * needs to read the input in advance in order to raise the
 * signals as fast as possible.
 * For example, when the user hits Ctrl+C, we can't wait until
 * the application consumes all the read events.
 * The same applies to echoing, when enabled, as the echoing
 * has to happen as soon as the user hit the keyboard, and not
 * only when the application running in the terminal processes
 * the input.

[stalep]

LineDisciplineTerminal is not used directly except for tests. If used directly it is extended by ExternalTerminal which creates a reader thread that will process the input bytes (echo for instance and signals).
ExternalTerminal is used when the java process is started as part of a series of commands eg. if the input is redirected in etc.
Is that sufficient?

[gnodet]

ExternalTerminal is supposed to be used for all terminals but the system one, i.e. the terminal which is used by the end user to launch the application. So all incoming connections should use the ExternalTerminal.
The original design was to work as close as possible as real Unix terminals, i.e. read the input, process the signals, and push the data into an internal buffer. This allows signals and echoing to work in advance, i.e. before the receiving application actually processes the input.

A simple example is how the sleep command works in a unix shell. If you run sleep 100, the terminal is in canonical mode when the sleep command is executed. Until the timeout is over, or until ^C is hit, you can type characters on your keyboard. Given the terminal is in canonical mode, it will have the echo flag set, so chars will be immediately echoed, even if they are not yet consumed by the sleep method.
The problem with the LinePipedInputStream is that it will only read until the first <enter> key, so if you hit <enter>, then <ctrl+c>, the interrupt signal won't be processed.

The terminal implementations did support those use cases, and I'd like to understand what use case is being solved by the introduction of the LinePipedInputStream class.

[stalep]

The reason we created LinePipedInputStream is when æsh-readline is started locally when part of a pipeline or redirection. The inputstream is then returned as a stream that could be read in its full length in one go. With LinePipedInputStream it will still read the entire buffer, but it will only return in chunks separated by the line.separator sign.
It will still receive signals, but again, this is only used for pipelines/redirections.