I'm serving Lanterna over telnetd as a text terminal.

OS X terminals, such as Terminal.app or iTerm2, send Enter as \r\u0000 (carriage return followed by null), which was not recognized by the provided key mapping profiles.

I added my own profile containing this pattern. This correctly recognized it as Enter, but it was also being wrongly intercepted by the CtrlAndCharacterPattern, because \r is int 13 and appears to be a control character. The pattern excludes \n and \t, but not \r. I think it should.

Once I've modified CtrlAndCharacterPattern#match method to also test for \r, everything worked correctly.

I haven't seen a way to do this other than modifying the source. There is no access to the collection of key mapping profiles provided in a text terminal, other than adding to it.

Patch is applied, please give it a try if you have a chance to.

This works.

However, I found a similar problem when using DOS or PuTTy clients on Windows. The Enter key sends the pattern \r\n. When added to the PuttyProfiles, Enter is recognized correctly. Attached patch.

That's odd, I haven't seen this behaviour with Putty before. Are you running it with the default settings?

Just plain Putty and DOS telnet connections.

I am serving lanterna as the shell for the telnetd library, sharing the input stream. To my knowledge, the input stream is not modified in any way. I can look further if you have other ideas.

This issue has been closed because Google Code is shutting down shortly and all issues have been migrated, along with the rest of the project, to GitHub. However, notifications will probably not work when updates are made to this issue on GitHub so for future updates, please visit https://github.com/mabe02/lanterna/issues and subscribe to further updates there.

Thank you, Martin