Coder Social home page Coder Social logo

jline3's Introduction

JLine License Maven Central Build Status: Linux Build Status: Windows

JLine is a Java library for handling console input. It is similar in functionality to BSD editline and GNU readline but with additional features that bring it in par with ZSH line editor. People familiar with the readline/editline capabilities for modern shells (such as bash and tcsh) will find most of the command editing features of JLine to be familiar.

JLine 3.x is an evolution of JLine 2.x.

License

JLine is distributed under the BSD License, meaning that you are completely free to redistribute, modify, or sell it with almost no restrictions.

Documentation

Forums

Artifacts

JLine can be used with a single bundle or smaller fine-grained jars. The bundle contains all jars except jline-groovy that must be included in classpath if you want to use scripting capabilities. The big bundle is named:

jline-${jline.version}.jar

The dependencies are minimal: you may use JLine without any dependency on *nix systems, but in order to support windows or more advanced usage, you will need to add either Jansi or JNA library.

You can also use fine grained jars:

  • jline-terminal: the Terminal api and implementations
  • jline-terminal-jansi: terminal implementations leveraging the Jansi library
  • jline-terminal-jni: terminal implementations leveraging the JNI native library
  • jline-terminal-jna: terminal implementations leveraging the JNA library
  • jline-terminal-ffm: terminal implementations leveraging the Foreign Functions & Mapping layer
  • jline-native: the native library
  • jline-reader: the line reader (including completion, history, etc...)
  • jline-style: styling api
  • jline-remote-ssh: helpers for using jline with Mina SSHD
  • jline-remote-telnet: helpers for using jline over telnet (including a telnet server implementation)
  • jline-builtins: several high level tools: less pager, nano editor, screen multiplexer, etc...
  • jline-console: command registry, object printer and widget implementations
  • jline-groovy: ScriptEngine implementation using Groovy
  • jline-console-ui: provides simple UI elements on ANSI terminals

JANSI

The JANSI project has been merged into JLine. The following artifacts are available:

  • jansi-core: the fine-grained jar containing jansi
  • jansi: a jar bundle which contains jansi-core and the needed jline dependencies

Supported platforms

JLine supports the following platforms:

  • FreeBSD
  • Linux
  • OS X
  • Solaris
  • Windows

FFM vs JNI vs Jansi vs JNA vs Exec

To perform the required operations, JLine needs to interoperate with the OS layer.
This is done through the JLine TerminalProvider interface. The terminal builder will automatically select a provider amongst the ones that are available.

On the Windows platform, relying on native calls is mandatory, so you need to have a real provider (jline-terminal-xxx jar) registered and its dependencies available (usually the Jansi or JNA library). Failing to do so will create a dumb terminal with no advanced capabilities.

By default, the following order will be used.

FFM

The FFM provider is available since JLine 3.24 and when running on JDK >= 22.
It's very lightweight with no additional dependencies. With JLine 3.26, the FFM provider requires JDK 22 with the --enable-native-access=ALL-UNNAMED JVM option.
Note that JLine 3.24 and 3.25 uses the preview version of FFM support shipped in JDK 21 which is incompatible with the final version in JDK 22.

JNI

Since JLine 3.24.0, JLine provides its own JNI based provider and native libraries. This is the best default choice, with no additional dependency. One requirement is that JLine will load a native library: this is usually not a problem, but it could be a limitation in certain environments.

JANSI

The Jansi library is a library specialized in supporting ANSI sequences in terminals. Historically, the JNI methods used by JLine were provided by Jansi. In order to minimize the maintenance cost, Jansi has been merged into JLine 3.25.

This provider has been deprecated in 3.26 in favor of the JNI provider.

JNA

The JNA library aims to provide an alternative way to access native methods without requiring writing a full JNI native library. If JNA is in JLine's class loader, the provider may be used. JNA is not supported on Apple M2 architectures.

This provider has been deprecated in 3.26 in favor of the FFM provider.

Exec

The exec provider is available on Posix systems and on Windows when running under Cygwin or MSys2. This provider launches child processes whenever the terminal is accessed (using Terminal.getAttributes, Terminal.setAttributes, Terminal.getSize, Terminal.setSize).

This provider also does not support external terminals (for example when creating a terminal for an incoming connection) and does not support the Windows native environment.

Maven Usage

Use the following definition to use JLine in your maven project:

<dependency>
    <groupId>org.jline</groupId>
    <artifactId>jline</artifactId>
    <version>${jline.version}</version>
</dependency>

JLine can also be used with more low-level jars:

<dependency>
    <groupId>org.jline</groupId>
    <artifactId>jline-terminal</artifactId>
    <version>${jline.version}</version>
</dependency>
<dependency>
    <groupId>org.jline</groupId>
    <artifactId>jline-terminal-jni</artifactId>
    <version>${jline.version}</version>
</dependency>
<dependency>
    <groupId>org.jline</groupId>
    <artifactId>jline-reader</artifactId>
    <version>${jline.version}</version>
</dependency>

All the jars and releases are available from Maven Central, so you'll find everything at the following location https://repo1.maven.org/maven2/org/jline/.

Building

Requirements

  • Maven 3.9.7+
  • Java 8+ at runtime
  • Java 22+ at build time
  • Graal 23.1+ (native-image)

Check out and build:

git clone git://github.com/jline/jline3.git
cd jline3
./build rebuild

Build Graal native-image demo:

./build rebuild -Pnative-image

Results

The following artifacts are build:

The big bundle includes everything (except jline-groovy) and is located at:

jline/target/jline-${jline.version}.jar

The jansi bundle is located at:

jansi/target/jansi-${jline.version}.jar

The fine grained bundles are located at:

terminal/target/jline-terminal-${jline.version}.jar
terminal-jansi/target/jline-jansi-${jline.version}.jar
terminal-jna/target/jline-jna-${jline.version}.jar
reader/target/jline-reader-${jline.version}.jar
style/target/jline-style-${jline.version}.jar
remote-telnet/target/jline-remote-telnet-${jline.version}.jar
remote-ssh/target/jline-remote-ssh-${jline.version}.jar
builtins/target/jline-builtins-${jline.version}.jar
console/target/jline-console-${jline.version}.jar
groovy/target/jline-groovy-${jline.version}.jar
jansi-core/target/jansi-core-${jline.version}.jar

Maven has a concept of SNAPSHOT. During development, the jline version will always end with -SNAPSHOT, which means that the version is in development and not a release.

Note that all those artifacts are also installed in the local maven repository, so you will usually find them in the following folder: ~/.m2/repository/org/jline/.

Running the demo

To run the demo, simply use one of the following commands after having build JLine

# Gogo terminal
./build demo

# Groovy REPL
./build repl

# Graal native-image
./build graal

Continuous Integration

jline3's People

Contributors

andrelfpinto avatar awegmann avatar bgerm avatar chirino avatar cosmin avatar ctubbsii avatar dattasid avatar dependabot[bot] avatar derklaro avatar electrum avatar fantasyzh avatar gnodet avatar headius avatar hns avatar hvesalai avatar hyee avatar jbonofre avatar jdillon avatar johnpoth avatar jvalkeal avatar marcono1234 avatar mattirn avatar mtyson avatar paulp avatar perbothner avatar snuyanzin avatar stephan-gh avatar tpoliaw avatar trptcolin avatar turbanoff avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jline3's Issues

should allow moving cursor with mouse

It's difficult to explain to non-geeks that you can't re-position the cursor with the mouse - and it's even (occasionally) annoying to us geeks!

The Python Prompt Toolkit supports using the mouse. It has similar goals as JLine3 (but for the Python eco-system), so it may be worth studying their solution.

LinuxNativePty should set attributes using the TCSADRAIN option

Since KARAF-4188, KARAF will use the JnaNativePty by default which causes the following infinite error loop on F24:

2016-09-02T13:30:49,505 | ERROR | Karaf local console user karaf | ShellUtil | 43 - org.apache.karaf.shell.core - 4.1.0.SNAPSHOT | Exception caught while executing command com.sun.jna.LastErrorException: [22] at com.sun.jna.Native.invokeVoid(Native Method) ~[?:?] at com.sun.jna.Function.invoke(Function.java:367) [?:?] at com.sun.jna.Function.invoke(Function.java:315) [?:?] at com.sun.jna.Library$Handler.invoke(Library.java:212) [?:?] at com.sun.proxy.$Proxy33.tcsetattr(Unknown Source) [9:jline:3.0.0.M1] at org.jline.terminal.impl.jna.linux.LinuxNativePty.setAttr(LinuxNativePty.java:71) [9:jline:3.0.0.M1] at org.jline.terminal.impl.AbstractPosixTerminal.setAttributes(AbstractPosixTerminal.java:36) [9:jline:3.0.0.M1] at org.jline.terminal.impl.AbstractTerminal.enterRawMode(AbstractTerminal.java:94) [9:jline:3.0.0.M1] at org.apache.karaf.shell.impl.console.JLineTerminal.enterRawMode(JLineTerminal.java:138) [43:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:444) [9:jline:3.0.0.M1] at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:390) [9:jline:3.0.0.M1]

This is due to the fact that attributes are set using the TCSANOW option. The TCSADRAIN option should be used when setting parameters that affect output.

Not able to resetPrompt like in JLine2

Perhaps I'm doing something wrong, but I'm not able to reset the prompt to keep moving it down below another threads output.

//this returns empty buffer even though something has been typed in BufferImpl buffer = this.reader.getBuffer();

Multiline support

Hello,

I am using jline3 to write a sql client. Some users write SQL sentences using multiple lines. A SQL command could have multiple lines and it finishes with a ';' in the end.

Is it possible to tell jline3 to use ; as the end of the line in LineReaderImpl (or in the class performing that job)?

Does not work with IDEA console or gradle console

Throws

org.jline.reader.EndOfFileException: org.jline.utils.ClosedException: InputStreamReader is closed.
        at org.jline.keymap.BindingReader.readCharacter(BindingReader.java:135)
        at org.jline.keymap.BindingReader.readBinding(BindingReader.java:68)
        at org.jline.keymap.BindingReader.readBinding(BindingReader.java:60)
        at org.jline.reader.impl.LineReaderImpl.readBinding(LineReaderImpl.java:675)
        at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:511)
        at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:392)

on LineReader::readLine

Problem with JnaNativePty

Hi,

I have noticed that the default terminal returned by TerminalBuilder.terminal() is not working.
The default configuration created by the builder on my system (Fedora 24) is equivalent to manually creating:
new PosixSysTerminal("jline", "xterm-256color", JnaNativePty.current(), "UTF-8", true);

And it gives the following error when calling LineReader.readLine() leaving the terminal unusable:

Exception in thread "main" com.sun.jna.LastErrorException: [22]
    at com.sun.jna.Native.invokeVoid(Native Method)
    at com.sun.jna.Function.invoke(Function.java:374)
    at com.sun.jna.Function.invoke(Function.java:323)
    at com.sun.jna.Library$Handler.invoke(Library.java:236)
    at com.sun.proxy.$Proxy21.tcsetattr(Unknown Source)
    at org.jline.terminal.impl.jna.linux.LinuxNativePty.setAttr(LinuxNativePty.java:71)
    at org.jline.terminal.impl.AbstractPosixTerminal.setAttributes(AbstractPosixTerminal.java:36)
    at org.jline.terminal.impl.AbstractTerminal.enterRawMode(AbstractTerminal.java:94)
    at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:444)
    at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:390)
    at pl.edu.agh.age.console.Console.mainLoop(Console.java:104)
    at pl.edu.agh.age.console.ConsoleBootstrapper.main(ConsoleBootstrapper.java:67)

However, the version with ExecPty works without problems:
new PosixSysTerminal("jline", "xterm-256color", ExecPty.current(), "UTF-8", true);

I don't think this is expected.

Candidates containing spaces lead to unexpected behaviour

Using only the following StringsCompleter resulted in an unexpected behaviour:
new StringsCompleter("foo bar abc", "foo bar xyz", "foobar")

Typing fo+tab worked alright.
Typing foo +tab was completed to foo foo.
Same is true for foo bar + tab and foo foo +tab.
foo b+tab lead to a / by zero exception.

The same completer worked fine with JLine 2.14.2.
Are Candidates supposed to represent only one word?

InfoCmp consumes about 128kb memory

When looking to reduce memory footprint of karaf, I noticed that InfoCmp consumes 128kb memory. This is mostly held by the NAMES map, which holds all the various permutations.
Could this be maybe restructured or even discarded after startup?

(yes I know. 128kb is not much. But its the third biggest consumer in this karaf runing on a low memory device.)

Echo disabled after creating terminal

This minimal example compiled with version: JLine 3.1.0 and JNA 4.2.2 disables the "echo" attribute of the terminal.

import org.jline.terminal.Terminal;
import org.jline.terminal.TerminalBuilder;
import java.io.IOException;

public class Test {
	public static void main(String... args) throws IOException {
		Terminal terminal = TerminalBuilder.builder().jna(true).build();
	}
}

Terminal returned from the builder is PosixSysTerminal with LinuxNativePty.

stty -a before running it:

speed 38400 baud; rows 76; columns 272; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

After:

speed 38400 baud; rows 76; columns 272; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl -echoke -flusho -extproc

Note change to echo in the last line.

problems with enabling MOUSE option

While enabling the new MOUSE option works pretty well, it has some annoying downsides: It interferes with mouse actions that aren't plain clicks. Specifically: selecting by dragging the mouse; middle-button-paste; right-button context menu; and scrolling using a wheel-mouse.

Most "xterm-compatible" terminal emulators allow you to get most of the default actions by using a shift-click (though mouse-scrolling doesn't work). However, this requires knowing (and remembering) to hit shift.

I'd like a mode such that:

  • clicking mouse-button-1 (non-shifted) is reported to the application
  • (on appropriate platforms:) middle-button-click reports the position the same way as mouse-button-1 and then the contents are the selection are sent to the application, using bracketed-paste-mode, similar to how a paste (ctrl-shift-V) works
  • all other mouse events are unmodified

Unfortunately, I don't believe there is any existing standard escape sequence to get this behavior. It should be easy enough to add for specific terminal emulators (I could do so for DomTerm), but it would be highly desirable to get at least Thomas Dickey (the xterm maintainer) to bless and document any new escape sequences.

(Architecturally, it would be better to move more of the editing into the terminal emulator, where we can integrate keyboard, mouse, selection, input methods, assistive technologies etc better. That is part of my vision for DomTerm. However, we should also improve the experience on more traditional terminal emulators.)

Nested ArgumentCompleter not working as expected

I tried to create a completer for the following command syntax:
Command1 [Param1 (Option1 | Option2) | Param2 | Param3]
Here is what I tried (JLine Version 3.0.1):

Terminal terminal = TerminalBuilder.builder().build();
Completer completer = new ArgumentCompleter(
        new StringsCompleter("Command1"),
        new AggregateCompleter(new ArgumentCompleter(
                new StringsCompleter("Param1"),
                new StringsCompleter("Option1", "Option2")
        ),
                new StringsCompleter("Param2", "Param3")
        )
);
LineReader lineReader = LineReaderBuilder.builder()
        .terminal(terminal)
        .completer(completer).build();
while (true) {
    lineReader.readLine();
}

Com + tab is completed correctly to Command1.
Command1 Par + tab is completed to Param2 Param3 but I expected Param1 to be in the list as well.
Command1 Param1 + tab is completed to Param2 Param3, so it is somehow parsed correctly as the completion still works (in the unexpected way). I expected Option1 Option2 in this case and that Param2 Param3 is only proposed again when an option is specified.
Command1 Param1 Opt + tab does not result in any completion proposals.

In case I misunderstood the architecture and this result is the expected one, I would appreciate some help how to implement my desired completer.

Infinite loop when reading empty string

Trying to upgrade from jline2 and ran into this. Here's a test to reproduce:

    @Test
    public void emptyStringGivesEOF() throws Exception {
        String inputString = "";
        InputStream inputStream = new ByteArrayInputStream(inputString.getBytes());

        LineReaderBuilder builder =
                LineReaderBuilder.builder()
                                 .terminal(TerminalBuilder.builder()
                                                          .streams(inputStream, System.out)
                                                          .build());

        LineReader reader = builder.build();

        // this gets trapped in an infinite loop
        assertNull(reader.readLine());
    }

Parser cancels Completer

I wrote a parser that checks if the line finishes with ';' and throws an error if it is not finishes like that

        if(!line.trim().endsWith(";")) {
            System.out.println("missing ;!");
            throw new EOFError(-1, -1, "Missing semicolon (;)", ";");
        }

I am writing an editor for SQL sentences using JLine3. The editor should support multiline sentences separated by ';'. I am following your suggestions about multiline support on ticket #36

At the same time I wrote a completer that would suggest SQL keywords.

It seems there is a conflict when the parser throws an error. When this happens, the completer never is queried so no suggestions are done to the user.

Example:

If user writes:

SELECT * FROM table

and then press tab, the parser throws and EOFError because the sentence did not finish with ';'. Parser does not know the user pressed key so it just checks if the sentence ends with a ';'...

In the #parse() method I cannot say if user pressed key looking for suggestions. So parser cannot say if the ';' is missing or the user did not finish to write the SQL query (perhaps he/she pressed key and he/she looking for autocomplete).

I am using Jline3 3.1.2 and it seems the issue happens in LineReaderImpl.java

        // Parse the command line and find completion candidates
        List<Candidate> candidates = new ArrayList<>();
        ParsedLine line;
        try {
            line = parser.parse(buf.toString(), buf.cursor(), ParseContext.COMPLETE);  // <-- EOFError() throwes here and execution goes to the catch section. Parser cannot say if <tab> key was pressed.
            if (completer != null) {
                completer.complete(this, line, candidates);
            }
        } catch (Exception e) {
            return false;
        }

No sure if this is a bug or I am writing a wrong parser. If parser has information about user pressing key, it could avoid throwing an exception.

Any suggestion?

excessive line-wrapping in Nano

Start up Nano (I do ./demo/jline-gogo.sh jna followed by typing nano) you get a normal-looking text editor. But if you're running in a decent xterm-comptible terminal emulator, select/copy the entire screen, and paste it (for example into an emacs buffer), you see it's all one long line.

It's especially obvious if running under DomTerm since it explicitly indicates line-wrapping (similar to how Emacs does it). Notice the arrow-things on the right:
nano-bad-wrap

UserInterruptException not thrown on ctrl-C

We've been using jline2 for the Presto CLI and everyone loves it. Just noticed the new jline3 project and started playing with it. Looks awesome!

I tried a basic example:

Terminal terminal = TerminalBuilder.terminal();
LineReader reader = LineReaderBuilder.builder().terminal(terminal).build();
while (true) {
    try {
        reader.readLine("> ");
    }
    catch (UserInterruptException e) {
        System.out.println("Interrupted: " + e.getPartialLine());
    }
    catch (EndOfFileException e) {
        break;
    }
}

On Mac Terminal, pressing ctrl-C causes the program to exit after a short delay (~1 second). I tried catching Throwable and a finally block, but neither get called, so the readLine() method is causing the JVM to exit.

LineReaderImpl in response to state == INTERRUPT, but state is never set to that (that enum value isn't used elsewhere).

I sent the original patch for UserInterruptException in jline2 and it worked by disabling interrupt handling for the terminal, allowing the key to be read as normal input. jline3 seems to be handling it by catching SIGINT. I wonder if that's less reliable? Were there problems with the other method?

Problem with command prompt

I'm currently trying to update from jLine2 to jLine3 but I'm having problems creating a command prompt which always "stays as the bottom". This is want I'm currently testing with.

public class Main {

    public static void main( String[] args ) {
        new Main();
    }

    private Terminal terminal;
    private LineReader reader;

    private Main() {
        try {
            this.terminal = TerminalBuilder.terminal();
            this.reader = LineReaderBuilder.builder().terminal( terminal ).build();

            Thread thread = new Thread( new Runnable() {
                @Override
                public void run() {
                    while ( !Thread.interrupted() ) {
                        try {
                            Thread.sleep( 1000 );
                        } catch ( InterruptedException e ) {
                            break;
                        }

                        terminal.writer().println( "test" );
                        terminal.flush();
                    }
                }
            } );
            thread.start();

            String line;
            while ( !Thread.interrupted() ) {
                line = reader.readLine( "> " );

                if ( line == null ) {
                    continue;
                }

                if ( line.equalsIgnoreCase( "quit" ) ) {
                    thread.interrupt();
                    System.exit( 0 );
                    break;
                }
            }
        } catch ( IOException e ) {
            e.printStackTrace();
        }
    }

}

Link to google group topic https://groups.google.com/forum/#!topic/jline-users/VBLZ6Wn15LY

Change Maven group ID to org.jline

Now that the Java package was changed to org.jline it would make sense (in my opinion) to follow the same conventions for the Maven group ID and change it to use a proper identifier like org.jline.

A lot of projects were using the Maven coordinates like jline before, but most projects (e.g. Apache commons-lang) switched to the new conventions after a major version jump.

Modular build

Split JLine into multiple independant modules:

  • terminal
  • terminal-jna
  • terminal-jansi
  • reader
  • builtins

Issues detected while building with Maven in Win 10

2 errors detected, and finally hanging on "org.jline.reader.impl.MultiByteCharTest"
Platform is Win10 x64, below is the console output:

[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for jline:jline:jar:3.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: junit:junit:jar -> duplicate declaration of version 4.12 @ line 151, column 21
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-site-plugin is missing. @ line 373, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JLine 3.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ jline ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jline ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory D:\Green\Github\jline3\src\main\filtered-resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ jline ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 95 source files to D:\Green\Github\jline3\target\classes
[INFO]
[INFO] >>> maven-bundle-plugin:2.5.4:manifest (default) > process-classes @ jline >>>
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ jline ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jline ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] skip non existing resourceDirectory D:\Green\Github\jline3\src\main\filtered-resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ jline ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 95 source files to D:\Green\Github\jline3\target\classes
[INFO]
[INFO] <<< maven-bundle-plugin:2.5.4:manifest (default) < process-classes @ jline <<<
[INFO]
[INFO] --- maven-bundle-plugin:2.5.4:manifest (default) @ jline ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ jline ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] skip non existing resourceDirectory D:\Green\Github\jline3\src\test\filtered-resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ jline ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ jline ---
[INFO] Surefire report directory: D:\Green\Github\jline3\target\surefire-reports


T E S T S

Running org.jline.builtins.OptionsTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec - in org.jline.builtins.OptionsTest
Running org.jline.keymap.BindingReaderTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec <<< FAILURE! - in org.jline.keymap.BindingReaderTest
testBindingReaderUnicode(org.jline.keymap.BindingReaderTest) Time elapsed: 0.005 sec <<< FAILURE!
java.lang.AssertionError: expected:<Reference[insert]> but was:<Reference[foo]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.jline.keymap.BindingReaderTest.testBindingReaderUnicode(BindingReaderTest.java:69)

Running org.jline.keymap.KeyMapTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec - in org.jline.keymap.KeyMapTest
Running org.jline.reader.completer.ArgumentCompleterTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec - in org.jline.reader.completer.ArgumentCompleterTest
Running org.jline.reader.completer.DefaultParserTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.jline.reader.completer.DefaultParserTest
Running org.jline.reader.completer.NullCompleterTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.jline.reader.completer.NullCompleterTest
Running org.jline.reader.completer.StringsCompleterTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in org.jline.reader.completer.StringsCompleterTest
Running org.jline.reader.history.FileHistoryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.jline.reader.history.FileHistoryTest
Running org.jline.reader.history.HistoryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.26 sec - in org.jline.reader.history.HistoryTest
Running org.jline.reader.history.MemoryHistoryTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.jline.reader.history.MemoryHistoryTest
Running org.jline.reader.impl.BufferTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.jline.reader.impl.BufferTest
Running org.jline.reader.impl.CompletionTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec - in org.jline.reader.impl.CompletionTest
Running org.jline.reader.impl.DigitArgumentTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec - in org.jline.reader.impl.DigitArgumentTest
Running org.jline.reader.impl.EditLineTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.068 sec - in org.jline.reader.impl.EditLineTest
Running org.jline.reader.impl.HistorySearchTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec - in org.jline.reader.impl.HistorySearchTest
Running org.jline.reader.impl.KillRingTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec - in org.jline.reader.impl.KillRingTest
Running org.jline.reader.impl.MultiByteCharTest

i-search crashes with default setup

Using the default LineReader setup, typing any character in i-search (ctrl-S) crashes:

java.lang.IndexOutOfBoundsException: Index: -1, Size: 0
        at java.util.LinkedList.checkPositionIndex(LinkedList.java:560)
        at java.util.LinkedList.listIterator(LinkedList.java:867)
        at org.jline.reader.impl.history.DefaultHistory.iterator(DefaultHistory.java:283)
        at org.jline.reader.impl.LineReaderImpl.searchForwards(LineReaderImpl.java:2415)
        at org.jline.reader.impl.LineReaderImpl.doSearchHistory(LineReaderImpl.java:2255)
        at org.jline.reader.impl.LineReaderImpl.historyIncrementalSearchForward(LineReaderImpl.java:2188)
        at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:533)
        at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:388)
        at org.acz.jless.Main.main(Main.java:53)

Can't turn off echo in PowerShell

All echo flags are false and sill it prints echo line.

UPDATE
The same problem with cmd. In both cases I am using ConEmu, but it should not matter.

UPDATE 2
Seem to be specific to ExternalTerminal. Works fine in jna and jansi.

documented support for as-you-type syntax checking

This is a wishlist item, which I think would be very neat for a language REPL. I suspect it is already possible; if so it would be nice to have it documented (as in a "howto").

A number of IDEs (I'm most familiar with NetBeans) do as-you-type syntax checking: The IDE/compiler continuously re-compiles your source file automatically as you type (even before you save your file). It will highlight any errors or warnings it sees, perhaps with a squiggly line and hovers. We can't do squiggly lines on a normal terminal, but the following is as good.

After each edit (and maybe a small timeout), Jline sends the current text (or a delta) is to the client. The client response includes any error messages. JLine prints those below the input area, by default in red (or perhaps orange for warnings). In addition, the location of the error in the input area is highlighted: For compilers that report a character range for an error, that range would be colored (for example an orange background); for compilers that report only a position, the character at that position would be highlighted.

This could be combined with accurate syntax highlighting: For example the compiler can report whether an identifier is a definition or a use, so we can highlight the former but not the latter.

Problems resetting the pty on linux+jna

Exception in thread "main" com.sun.jna.LastErrorException: [22] °§Ð
    at com.sun.jna.Native.invokeVoid(Native Method)
    at com.sun.jna.Function.invoke(Function.java:374)
    at com.sun.jna.Function.invoke(Function.java:323)
    at com.sun.jna.Library$Handler.invoke(Library.java:236)
    at com.sun.proxy.$Proxy0.tcsetattr(Unknown Source)
    at org.jline.terminal.impl.jna.linux.LinuxNativePty.setAttr(LinuxNativePty.java:75)
    at org.jline.terminal.impl.AbstractPosixTerminal.close(AbstractPosixTerminal.java:64)
    at org.jline.terminal.impl.PosixSysTerminal.close(PosixSysTerminal.java:85)
    at org.apache.felix.gogo.jline.Main.main(Main.java:96)

StringIndexOutOfBoundsException if old style history file is found

If you have run previous versions of jline there might be a history file in old syntax.
There each line just had the command. So there is no ":" which causes the exception below.
This error prevents the shell from starting.

A workaround is to remove the old history file.

StringIndexOutOfBoundsException: String index out of range: -1
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1967)
at org.jline.reader.impl.history.DefaultHistory.lambda$load$0(DefaultHistory.java:80)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
at org.jline.reader.impl.history.DefaultHistory.load(DefaultHistory.java:78)
at org.jline.reader.impl.history.DefaultHistory.attach(DefaultHistory.java:66)
at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:444)
at org.apache.felix.gogo.jline.Shell.runShell(Shell.java:396)
at org.apache.felix.gogo.jline.Shell.gosh(Shell.java:323)
at org.apache.felix.gogo.jline.Activator.doStartShell(Activator.java:150)
at org.apache.felix.gogo.jline.Activator.lambda$startShell$0(Activator.java:106)
at java.lang.Thread.run(Thread.java:745)

How do you compile and run the Example.java example?

Hello,

I compiled the jline program with mvn install then moved the example file and the jar file to a common directory. Then I tried to compile the file and run it.

javac -cp jline-2.15-SNAPSHOT.jar Example.java
java Example 

This gave an error of Error: Could not find or load main class Example. I also tried java -cp jline-2.15-SNAPSHOT.jar Example but got the same error.

I come from a Scala background and not a Java background so I am sure I am missing something simple.

Oh yeah. I did the same thing with both the master branch of the jline2 and the jline3 repos.

Thanks for you help.

Problems with cursor (arrow) keys and CTRL+anything in jline3

I try to use jLine (3.1.2) as shell in apache's sshd-core.
So I use TerminalBuilder/LineReaderBuilder to setup jLine as seen in the documentation.

Most of the stuff I would like to do is working.
But some features I would like to use are not working at all.

It already was a long way to get CTRL+C and CTRL+D working, as it seems like ControlChar.VEOF and ControlChar.VINTR are undefined as default (-1).

So pressing e.g. CTRL+C resulted in a unprintable character which int representation was 3.
I fixed that problem by using setControlChar(ControlChar.VINTR, 3) on the attributes provided by TerminalBuilder.
Same thing goes for CTRL+D (which sends a character with id 4).

Now I'm still struggling with the usage of the cursor-keys (to e.g. use the history).

When pressing any of the cursor keys, I only get 'oA' or 'oB' etc. depending on which cursor key I used.

Is there any option I have enable to get the cursor keys working?

btw. using jLine 2 is working in my setup, but it messes up with line-feed/carriage return...

Sample code:

    Attributes termAttribs = new Attributes();
    // enable output processing (required for all output flags)
    termAttribs.setOutputFlag(OutputFlag.OPOST, true);
    // map newline to carriage return + newline
    termAttribs.setOutputFlag(OutputFlag.ONLCR, true);

    // enable signals (for CTRL+C usage)
    termAttribs.setLocalFlag(LocalFlag.ISIG, true);
    // print control chars as '^X' (e.g. ^C for CTRL+C)
    termAttribs.setLocalFlag(LocalFlag.ECHOCTL, true);

    // enable CTRL+D shortcut
    termAttribs.setControlChar(ControlChar.VEOF, 4);
    // enable CTRL+C shortcut
    termAttribs.setControlChar(ControlChar.VINTR, 3);

    terminal = TerminalBuilder.builder()
            .system(false)
            .streams(getInStream(), getOutStream())
            .signalHandler(Terminal.SignalHandler.SIG_IGN)
            .nativeSignals(true)
            .attributes(termAttribs).build();

    reader = LineReaderBuilder.builder()
            .terminal(terminal)
            .build();

    reader.unsetOpt(Option.INSERT_TAB); // disable tab insertion when no letter was given (allows using tab to list all commands)

    // output welcome banner on ssh session startup
    if ((shellGreeter != null) && !shellGreeter.isEmpty()) {
        for (String line : shellGreeter) {
            terminal.writer().println(line);
        }
        terminal.flush();
    }

    String readline;
    while ((readline = reader.readLine(prompt)) != null) {
        handleUserInput(readline); // handles the input, executes what ever command
    }

automatic and accurate balanced brackets

JLine does have simple bracket "bouncing": Type a closing paren/bracket, and the cursor briefly jumps to the open paren/bracket. However, this is both inaccurate (it gets fooled if a paren/bracket is escaped or quoted) and incomplete (it doesn't handle string quotes, for example) - which is harmless, since it's only a brief bounce.

Some IDEs go further, and actually insert a closing bracket when you type type the open bracket. One may have mixed feelings about this, but I believe it is highly desirable when doing as-you-type syntax checking (issue #46), so the compiler can work with a closer-to-valid program fragment. However, if one does that, it is important to be accurate, which means consulting the compiler.

Some complications to note: We want to handle "brackets" where the open and close character are the same - for examples quotes for string literals. We want to handle multi-character "brackets" for example /* and */ for C-style comments. XML literals are even more complex: <p></p>.

It is important that the user be able to explicitly type a closing bracket without getting a duplicate. I.e. after typing ( the display is (); typing + updates it to (+) with the cursor before the ); typing ) updates it to (+) with the cursor after the ). In general, when typing a character x if the cursor is already before the same character x and x is part of a closing "bracket", just move the cursor past the x rather than adding a new one. The tricky part is determining when x is part of a closing bracket: the compiler can give JLine that information, bundled with syntax highlighting.

To cause opening brackets to insert closing brackets is more complicated. When the user types a character, in addition to inserting it the input area, JLine needs notify the compiler about which character was typed and where; if the character was the last character of an opening bracket the compiler responds back to JLine with the closing bracket to insert.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.