jline / jline2 Goto Github PK

I'm now seeing this in the example code after exiting, and this also happens in my code using jline when running on master:

colin:jline2/ (master) $ java -cp target/jline-2.7-SNAPSHOT.jar:target/jline-2.7-SNAPSHOT-tests.jar jline.example.Example none
prompt> asdf
======>"asdf"
prompt> [Ctrl-d here]
Exception in thread "JLine Shutdown Hook" java.util.ConcurrentModificationException
    at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
    at java.util.AbstractList$Itr.next(AbstractList.java:343)
    at jline.internal.ShutdownHooks.runTasks(ShutdownHooks.java:73)
    at jline.internal.ShutdownHooks.access$000(ShutdownHooks.java:33)
    at jline.internal.ShutdownHooks$1.run(ShutdownHooks.java:58)

git bisect says this started happening at c70d475. I think this is because the hook removal is now allowed to happen in the same thread as the iteration. Previously it was protected from this because iteration happened in a separate thread from removal, and they were guaranteed not to happen at the same time because of the static synchronized business on the ShutdownHooks class.

jline2 embeds jansi, which in turn embeds the org.fusesource.hawtjni.runtime.Library class. This is vulnerable to CVE-2013-2035:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2035

HawtJNI 1.8 has been released, incorporating a fix for this flaw. Jansi 1.11 has been released, embedding HawtJNI 1.8 and incorporating a fix for this flaw.

Would it be possible to get the latest from master into a SNAPSHOT sometime soon?

I'm also interested in a non-SNAPSHOT release.

I've got a Clojure REPL dependent on jline2, and I'd love to be able to point it at with the official distribution instead of my own jar, and also to do away with any SNAPSHOT resolution.

Thanks for maintaining this project!

Hi,

Isn't there some link to the Jline2 .jar, instead of having to install Git software and build the .jar? I just need to be able to get a character from the console, without having to press Enter. I've been searching around, and trying suggestions on the Web, for more than 4 days, but nothing seems to work. Jline2 seems to require a Git account, and a build, just to use some simple functionality in a project.

due to unix logic in FilenameCompletor:

else if (!(translated.startsWith(separator()))) {

this should be an os independent implementation of ! isAbsolute(translated)

Else using "C:\foo" as translated creates junk.

There's a report at technomancy/leiningen#850 of this issue on Windows + cygwin + mintty, which sounds like it's not detecting the need for UnixTerminal. @orfjackal has included a workaround that fixes things for him, but it seems like ideally this would be done by jline so that projects using jline don't all have to do the same workaround.

I haven't reproduced this locally yet, but I thought I'd remembered seeing things work as expected in cygwin. Could just be mis-remembering, because the terminal selection code appears to be only based on OS name.

Thoughts?

#35

Adding the following plugin to the pom.xml solves that issue for me.

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>2.1.2</version>
            <executions>
                <execution>
                    <id>attach-sources</id>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

Hi,

Sorry this is a weak bug report, but here it goes...

I had a strange issue using the leiningen repl, which is based on JLine2. My .inputrc looked like this:

$ cat ~/.inputrc
"\e[A": history-search-backward
"\e[B": history-search-forward

...which, as I understand it, is supposed to map arrow keys to scroll though command history. The up/down arrow keys did nothing, until I renamed .inputrc to .inputrc.old. Then the repl worked fine.

Thanks,

• Chris

when i do a call ConsoleReader.readLine("Input Password:","*") in Eclipse, an infinite loop of output "Input Password" is triggered. Maybe It's only happen when I test my code in Eclipse.

(I've already reported this in issue 54 but It's closed so I'm opening this new one)

I'm having this problem with the scala REPL.

Home Key:
scala> 7~

End Key:
scala> 8~

I added the following to my .inputrc (taken from /etc/inputrc) to no avail:

"\e[7~": beginning-of-line
"\e[8~": end-of-line

For the time being I will disable jline and fall back to readline, but I would like to re-enable it in case there is a solution.

As seen is: Polymer/polymer@0940bc5

Calling readLine(">") or similar, and then doing a flush + drawline() from the same thread will result in the prompt being doubled up like so: ">>"

The LogManager class referenced above is a good example of how to do this.

working with jline 1.0.
i would like to support auto indent, meaning in readLine, after the prompt is rendered, blanks would be printed after the prompt as if the user had typed them, meaning the user can also delete them.
Currently i see no way to do this in jline1.0, extending the prompt would not allow deleting chars.

Similarly it would be nice if there was a callback to interact more, such as when the user types a "}" bracket after two blanks, readline would replace the blanks with "}", instead of appending.

From JRUBY-6787: http://jira.codehaus.org/browse/JRUBY-6787

When a bash .inputrc contains the following lines, it appears to break up/down arrow behavior in a console using jline:

{noformat}
"\e[A": history-search-backward
"\e[B": history-search-forward
{noformat}

I'm not really familiar with bash, but the readline equivalent to history-search-backward is Ctrl-r, which does work properly in jline.

Expected behavior would be that up and down get bound to (and cause to happen) the appropriate readline equivalents of forward and backward history searching.

When jline is used on the server side through SSH, the client may send character sequences (such as arrows) into a different encoding, thus leading to a bad transformation of the stream and unrecognized sequences.

See https://issues.apache.org/jira/browse/KARAF-542?focusedCommentId=13036920&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13036920

There's one nuance that should be fixed. In Unix you can add the line break in the middle of a command like this:
$ ech\

o Hell World!
Hell World!
$

But in Karaf, the line break is adding a space so the same command fails:
karaf@root> ech\

o Hello World!
Error executing command: Cannot coerce hello(String) to any of []
karaf@root>

Jline is inserting a space where the line break is. This shows the space better:
karaf@root> echo 123\

456
123 456
karaf@root>

It also doesn't handle quoting correctly. On Unix:
$ echo "123\

456"
123456
$

On Karaf:
karaf@root> echo "123\

456"
123\ 456
karaf@root>

There are a few additions in the Scala implementation's keyboard bindings:

ctrl-d: exit (EOF character)
meta-d: delete the next word
delete: delete the next character

I'd like to have those in this project too. I can work on a patch soon if nobody else gets to it first.

Hi,

When using jline, while connecting to a terminal with putty, I'm unable to use the home and end keys for going to the beginning and end of the line. jline outputs "~1" and "~4" instead. I have tried all sorts of putty settings, TERM settings, bash, zsh and .inputrc settings. Home and end works on the commandline and in other programs. The problem is specific to jline. I have also tried editing the keybindings.properties file.

As I understand, these are the bindings that jline should have:

 bind '"\e[1~": beginning-of-line'
 bind '"\e[4~": end-of-line'

However, reading the UnixTerminal source code, it seems like only single character keystrokes are interpreted, with the exception of unicode.

Please add support for home and end while using putty.

Best regards,
Alexander Rødseth

Readline itself supports setting blink-matching-paren (in ~/.inputrc, but it's on by default) to blink the opening parenthesis when entering the closing one. This is helpful whenever you have nested parentheses (or [] or {}), and of course especially in a Lisp.

So it would be awesome for Clojure jline consumers, in particular, to have this feature available.

The way readline does it is to find the matching opening paren, back the cursor up to that point, select on input for half a second (_paren_blink_usec), then move the cursor back. Any input would stop the waiting and resume normal behavior.

Does it seem like a good plan to duplicate this feature?

When you do [ConsoleReader instance].readLine() the following oddity with backslashes exists:

\ - single backslash is simply ignored
\ - two backslashes is represented as single backslash
\\ - three backslashes is represented as two backslashes \
etc

I've turned off event-expanding (when typing Clojure literals that contain "!" into a REPL, for instance), and that works great for normal commands, but this line in MemoryHistory.java causes the history to be written escaped (for events):

item = item.toString().replaceAll("\\!", "\\\\!"); 

The two options I see are (a) to give the History a knowledge of whether expandEvents is turned on in the Reader, or better yet, (b) perform the escaping on the String before sending it to the History with history.add (in ConsoleReader#finishBuffer).

I've held off making a patch for now, to await input on which is the preferred solution. Or maybe there are other solutions too.

It always prints out the line entered, even if the mask is NULL_MASK. This works for org.sonatype.jline version 2.5 but was broken at some point in 2.6-SNAPSHOT.

I encountered the following exception on a few machines (Win XP) using the latest jline:

"java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32"

Some research showed that some Microsoft DLL could not be found or loaded, don't really understand it, but here is a link to it with references:

http://comments.gmane.org/gmane.comp.lang.scala.user/40653

Basically installing the library from this URL fixed it

http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2

Leiningen 2.0.0-preview7 on Java 1.6.0_26 Java HotSpot(TM) 64-Bit Server VM

lein repl
nREPL server started on port 35339
REPL-y 0.1.0-beta8
Clojure 1.4.0

At the repl, home and end keys just type H and F respectively

~/code/jline2(master) $ java -cp target/jline-2.7-SNAPSHOT.jar:target/jline-2.7-SNAPSHOT-tests.jar jline.example.Example none
prompt> foo bar baz foo bar baz foo bar baz foo bar baz foo bar baz foo bar baz foo ba;86Rr baz

Notice towards the end there are some characters: ;86R. I keep getting this whenever I move around the text with the arrow keys (left and right). It is spontaneous and doesn't happen for every key stroke, but consistently happens every 30 or so.

This is in bash on iTerm 2 in OS X. The jline version used in the above example is SHA: 5dcfc6b

Details on:
https://jira.codehaus.org/browse/JRUBY-6587

the following code never prints
the commented out items work with JLine-1.0.jar

(if readCharacter() is not a replacement for readVirtualKey() then this issue is void)

import jline.console.ConsoleReader;
//import jline.ConsoleReader;

public class JLineTester {

  public static int val = 0;

  public static void main(String[] args) {
    try {
      final ConsoleReader cr = new ConsoleReader();
      int key = 0;
      while(key != 3) {
        key = cr.readCharacter();
        //key = cr.readVirtualKey();
        System.out.println(key);
        }
    } catch (Exception e) { e.printStackTrace(); }
  }
}

Note: I can put System.out.println(c) in the readCharacter() and it will print in that method

What works on numpad: Arrows, Del key, enter key
What doesn't work on numpad: Home/End/Insert/PgUp/PgDn when pressed they output the chars G/O/R/I/Q (that is, pressing Insert on numpad it puts the R char as if you pressed Shift+r and capslock was off)
When I say numpad I mean numlock is off 'cause when it's on it just inserts the digits.

The normal (non-numpad located) keys Home/End/Insert/PgUp/PgDn work.

I was excited to see a fork of jline. I found it hoping to use it in conjunction with jdb, as jline-1.0 has some weird behavior on my terminal. But I can't figure out how to run jdb with it. There's no jline.ConsoleRunner or equivalent that I can tell.

The command I was using is

java -cp /usr/share/java/jline-1.0.jar:/usr/lib/jvm/java-1.6.0-openjdk/lib/tools.jar jline.ConsoleRunner com.sun.tools.example.debug.tty.TTY

Any suggestions on running jdb with jline2?

I'm using jython 2.5.3 interpreter in linux with the bundled jline. The version that comes with jython is 0.9.95, and I tried swapping the jline jar for jline 1.0 and 2.8 with no change.

Current behavior: When I hit ctrl+left or ctrl+left it just prints out "1;5D" or "1;5C", respectively.
Desired behavior: cursor moves to the left or right by one word.

Is there a way to produce this behavior by modifying the .jlinebindings.properties file, the .inputrc file, or does that require changing jline to support those keyboard shortcuts? (I realize that there are alternative keyboard shortcuts which provide this same behavior, but I would prefer to use these if possible as they work that way in most of the apps I use including bash, (i)python, and most graphical (non emacs/vi) editors)

Also, is there more (end-user) documentation about what key codes and logical operations can be bound in the .jlinebindings.properties file?

[WARN] Failed to query stty columnsjava.lang.InterruptedException
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.UNIXProcess.waitFor(UNIXProcess.java:210)
    at jline.internal.TerminalLineSettings.exec(TerminalLineSettings.java:196)
    at jline.internal.TerminalLineSettings.exec(TerminalLineSettings.java:170)
    at jline.internal.TerminalLineSettings.stty(TerminalLineSettings.java:165)
    at jline.internal.TerminalLineSettings.get(TerminalLineSettings.java:69)
    at jline.internal.TerminalLineSettings.getProperty(TerminalLineSettings.java:89)
    at jline.UnixTerminal.getWidth(UnixTerminal.java:75)
    at jline.console.ConsoleReader.drawBuffer(ConsoleReader.java:610)
    at jline.console.ConsoleReader.drawBuffer(ConsoleReader.java:629)
    at jline.console.ConsoleReader.drawLine(ConsoleReader.java:357)

I'm really new to Java and I don't really understand Unix at all. I've gotten jline2 working on Windows, but another person is seeing this exception with the solution now. Is this something obvious to anyone here or do I need to dig more?

Please implement non-blocking console input, e.g. ConsoleReader.readCharacterNoWait(). It would only require a minor change in NonBlockingInputStream and ConsoleReader.

I'm writing a console-mode communications tool, where I have to read from the console without blocking. I know that I could use a separate thread to do that.

I tried the following code:

ConsoleReader con = new ConsoleReader();
NonBlockingInputStream in = (NonBlockingInputStream)(con.getInput());
int key = in.read(1);

But: 1. i'ts not guaranteed that future versions of ConsoleReader.getInput() will return a NonBlockingInputStream and 2. it blocks 1ms if no keyboard input is ready.

On my Windows 7 system, ConsoleReader uses the character set encoding "windows-1252" to decode keyboard input codes, but the keyboard codes arrive in "Cp437".

When I use the default constructor of ConsoleReader and use ConsoleReader.readCharacter() to read the keys ä ö ü. the Unicode character values are 8222, 8221 and 65533, which is wrong.

When I use "Cp437" to construct the ConsoleReader, ConsoleReader.readCharacter() delivers the correct values 228, 246 and 252.

The Win32 API call GetOEMCP() could be used to get the correct code page. The Windows command CHCP displays the same code page number (437 in my case).

In those two modes ctrl-c seems still mapped to a plain insert of \u0003.

When migrating to jline2, API call do not seem compatible.

for example: ConsoleReader.readVirtualKey is now ConsoleReader.readCharacter

Are there plans to incorporate aliases to these methods?

"Shutdown hooks causes classloader leakage in sbt, so they are only installed if -Djline.shutdownhook is true."

This causes my terminal to not be reset when exiting resulting in no characters echoed until i reset manually. This is a change from jline1's default and i suspect i won't be the only one to run into this.

For non-sbt users, it can be resolved by adding this to .jline.rc:

 jline.shutdownhook=true

But maybe jline2 could instead check if an sbt class is loaded and disable the hook? It'll be kinda cumbersome for users like me since adding the .jline.rc will interfere with sbt for me, meaning i'll have to manually enable the hook everywhere else.

I really miss the following bindings (got used to them with gnu readline)

• M-<backspace> ==> Operation.BACKWARD_KILL_WORD
• M-b ==> Operation.BACKWARD_WORD
• M-f ==> Operation.FORWARD_WORD
• M-d ==> Operation.KILL_WORD
• C-y ==> Operation.YANK

Hi,
I am getting the following messages printed. Any hint why?

[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: prefix-meta
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history
[INFO] Unable to bind key for unsupported operation: up-history
[INFO] Unable to bind key for unsupported operation: down-history

Thanks!

I am having an issue with jline version 2.9 under OSGi.

I want to extend the UnixTerminal class and use my own implementation which sets to undef additional control characters. UnixTerminal has TerminalLinesSettings as a property so my custom UnixTerminal has to import that class. The problem is that this class is contained inside a package that is not exported.

I tried having that package as a private package inside my bundle, but this leads to LinkageErrors.

So currently, the only solution for me is to "copy" some jline classes inside my bundle, which is not the nicest thing.

Some possible soltions would be to export jline.internal package or move TerminalLineSettings under the same package with UnixTerminal.

I am working on upgrading my shell program (jsqsh) to jline 2.6. In my .inputrc I have "vi" mode enabled and when I launch my shell, jline immediately places me in command mode and it appears that nothing but "k" and "j" work to navigate previous lines, but no other keystrokes work. I cannot enter edit mode or move the cursor any other way except up and down.

(I have gone ahead and created a ~/.jline.rc containing jline.terminal=auto since writing this issue.)
My issue is my control keys do not work, and what can I do to work around this issue.

Here is a description of what I've done.

I am running

java -cp target/jline-2.11-SNAPSHOT-tests.jar:target/jline-2.11-SNAPSHOT.jar -Djline.internal.Log.debug=true jline.example.Example none

in my ~/jline2 directory, where I installed jline2. My control keys (ctrl+a, ctrl+e, ctrl+u and Backspace) do not work.

I am logging into an Ubuntu 12.04 system with bash as the shell and using a VanDyke SecureCrt terminal emulator product. I have made no recent settings changes to my emulator.

First, I notice I have no ~/.jline.rc file
[DEBUG] Loading properties from: file:/home/cnorton/.jline.rc
[DEBUG] Unable to read configuration from: file:/home/cnorton/.jline.rc
java.io.FileNotFoundException: /home/cnorton/.jline.rc (No such file or directory)

After the stack trace, here is the rest of the output.

[DEBUG] Creating terminal; type=auto
[DEBUG] Config: speed 38400 baud; rows 34; columns 117; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd 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

[DEBUG] Created Terminal: jline.UnixTerminal@1d520c4
[DEBUG] Registering shutdown-hook: Thread[JLine Shutdown Hook,5,main]
[DEBUG] Adding shutdown-hook task: jline.TerminalSupport$1@1e9cb75
[DEBUG] Ansi supported: true
[DEBUG] Echo enabled: false
[DEBUG] NonBlockingInputStream start
[DEBUG] Loaded user configuration: file:/home/cnorton/.inputrc
prompt> [DEBUG] Running all shutdown-hook tasks
[DEBUG] Running task: jline.TerminalSupport$1@1e9cb75
[DEBUG] Removing shutdown-hook: Thread[JLine Shutdown Hook,5,main]

Here is some more debugging output from running

export JLINE_LOGGING=trace && lein trampoline run
in a cloned directory
git clone git://github.com/trptcolin/reply.git
Please note the control keys work.

cnorton@steamboy:~/reply$ export JLINE_LOGGING=trace && lein trampoline run
REPL-y 0.2.0-SNAPSHOT
Clojure 1.4.0
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
(user/sourcery function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc](user/clojuredocs name-here)
(user/clojuredocs "ns-here" "name-here")
[DEBUG] Loading properties from: file:/home/cnorton/.jline.rc
[DEBUG] Loaded properties:
[DEBUG] jline.terminal=unix
[TRACE]
java.lang.Throwable: CREATE MARKER
at jline.TerminalFactory.create(TerminalFactory.java:50)
at jline.TerminalFactory.get(TerminalFactory.java:159)
at jline.console.ConsoleReader.(ConsoleReader.java:226)
at jline.console.ConsoleReader.(ConsoleReader.java:218)
at jline.console.ConsoleReader.(ConsoleReader.java:210)
at reply.reader.simple_jline$setup_console_reader.invoke(simple_jline.clj:39)
at reply.reader.simple_jline$get_input_line.invoke(simple_jline.clj:74)
at reply.reader.simple_jline$safe_read_line$fn__941.invoke(simple_jline.clj:101)
at clojure.lang.Atom.swap(Atom.java:37)
at clojure.core$swap_BANG_.invoke(core.clj:2108)
at reply.reader.simple_jline$safe_read_line.invoke(simple_jline.clj:99)
at reply.eval_modes.nrepl$safe_read_line.invoke(nrepl.clj:55)
at reply.eval_modes.nrepl$parsed_forms.invoke(nrepl.clj:88)
at reply.eval_modes.nrepl$run_repl.invoke(nrepl.clj:139)
at reply.eval_modes.nrepl$main.invoke(nrepl.clj:227)
at reply.main$launch_nrepl$fn__3187.invoke(main.clj:63)
at clojure.core$with_redefs_fn.invoke(core.clj:6585)
at reply.main$launch_nrepl.invoke(main.clj:62)
at reply.main$launch.invoke(main.clj:79)
at reply.main$_main.doInvoke(main.clj:89)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:411)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.Var.applyTo(Var.java:532)
at reply.ReplyMain.main(ReplyMain.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
at user$eval5.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6501)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$eval_opt.invoke(main.clj:297)
at clojure.main$initialize.invoke(main.clj:316)
at clojure.main$null_opt.invoke(main.clj:349)
at clojure.main$main.doInvoke(main.clj:427)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)

[DEBUG] Creating terminal; type=unix
[TRACE] Running: [sh,-c,stty -a < /dev/tty]
[TRACE] Result: speed 38400 baud; rows 34; columns 117; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd 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

[DEBUG] Config: speed 38400 baud; rows 34; columns 117; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd 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

[DEBUG] Created Terminal: jline.UnixTerminal@74a7af
[DEBUG] Registering shutdown-hook: Thread[JLine Shutdown Hook,5,main]
[DEBUG] Adding shutdown-hook task: jline.TerminalSupport$1@183e6d4
[DEBUG] Ansi supported: true
[TRACE] Running: [sh,-c,stty -icanon min 1 -icrnl -inlcr < /dev/tty]
[TRACE] Result:
[TRACE] Running: [sh,-c,stty -echo < /dev/tty]
[TRACE] Result:
[DEBUG] Echo enabled: false
[DEBUG] NonBlockingInputStream start
[DEBUG] Loaded user configuration: file:/home/cnorton/.inputrc
[TRACE] Loading history from: /home/cnorton/.jline-reply.history
user=> [TRACE] Running: [sh,-c,stty intr undef < /dev/tty]
[TRACE] Result:
[TRACE] Keystroke: 1
[TRACE] Binding: BEGINNING_OF_LINE
[TRACE] Keystroke: 5
[TRACE] Binding: END_OF_LINE
[TRACE] Keystroke: 21
[TRACE] Binding: UNIX_LINE_DISCARD
[TRACE] Keystroke: 127
[TRACE] Binding: BACKWARD_DELETE_CHAR

Having a line like these in ~/.inputrc prevents line input:

Control-j: next-history
Control-k: previous-history

Control-j is the problem one.

From the small bit of research I did, I see that Control-j is really the same as the Enter key, but in the only shell where I could get that setting to be used (bash), Control-j and Enter were treated differently. So maybe there's a way we can distinguish them in jline as well?

I was wondering if you have or are going to publish a JavaDoc for the new JLine API. Also is there any chance of some examples being published also? I am kind of new to Java and the lack of documentation is making it difficult to use your library which fit perfectly (in concept) with a project I am working on.

I see a commit which apparently introduced switching between vi/emacs mode (8584b6c). How do you switch or specify which mode to use to jline2? I can't find any documentation for this project.

Not sure if jline.internal.Log is subject to change, but currently the only way I could find to set its output was to set it directly on that class. It would be nice to have that option either through the ConsoleReader or maybe just a non-"internal" class.

Apologies if I'm missing something obvious about where this should be configured.

The two main issues:

• !n - because MemoryHistory uses zero-based numbering and event designators are 1-based, "!n" should retrieve history item (n-1); however, expandEvents does not take this offset into account, leading to incorrect expansion results for positive values of n.
• !-n - expandEvents throws an exception when you try to retrieve "!-n" where n = History.size().

I think this means there's no way to avoid the Log.warn dumping to System.out, unless client code is force both Log class loading and configuration until after ConsoleReader's class loading.

c6d9e1f#L1R52

Any chance of getting this out of static initialization, or making it a Log.trace or Log.debug? (or a tip for a workaround if I'm missing something!)

My .inputrc contains the following line:

Control-x:  shell-expand-line

Running lein2 repl fails because jline does not support the shell-expand-line binding value.

(See technomancy/leiningen#557 for the relevant lein bug.)

when pressing Ctrl+Left. Ctrl+Right, Ctrl+Up or Ctrl+Down, a NPE is thrown.
This incident also occurs when using the ALT key instead of CTRL.