16

I am looking for a GNU readline alternative. It comes with a lot of features but only couple of them are useful to me as explained below -

I am working on a interactive command prompt application (display prompt and accept next user command to be run). I want to implement some editing and history feature for the prompt. So when the user presses UP key it should show the last run command. Also, user should be able to navigate using arrow keys if he need to edit any typo or command switches etc.

On windows something similar already exists, if you use fgets or scanf to get the input on cmd prompt it already maintains history and also lets you edit.

Is there a good option available on linux?

punekr12
  • 653
  • 2
  • 7
  • 14
  • Seriously? Is that some kind of Visual Studio add-on? – Duck Jul 31 '13 at 23:28
  • @Duck thanks, I m using C. I am using VS but not sure if its an add-on. – punekr12 Jul 31 '13 at 23:37
  • 2
    what's wrong with just using readline? It's quite easy to integrate into your application. – rici Jul 31 '13 at 23:40
  • @rici it seems so feature rich, that I wanted to see if there is something simpler/lightweight – punekr12 Jul 31 '13 at 23:47
  • Take at look at the "external links" section here and see if any of them suits you. At least one of them requires ncurses so I don't think you are necessarily losing overhead with that. http://en.wikipedia.org/wiki/Readline – Duck Jul 31 '13 at 23:50
  • @punekr12: it's easier to ignore a feature you don't need than to implement one you do. Anyway, if I were you, I'd worry more about simplicity of interface than how much stuff it drags in behind it. There's a sample implementation of a gets() almost-drop-in (with the advantage of being overrun safe) in the readline manual, http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC23 – rici Jul 31 '13 at 23:57
  • 2
    rici and Duck are absolutely right. In Linux, even the terminal window size may change at any point in time, so the library must redraw the line appropriately. Furthermore, since locales support various character sets and nonprinting and special sequences, the library must be able to count *glyphs* instead of input bytes to keep track of how long the input is on-screen, while the in-memory length may be completely different. I'd go with `readline()` from the readline library simply because of its ease of use and user-friendliness. (Users like me have their own quirks set in `~/.inputrc`.) – Nominal Animal Aug 01 '13 at 00:03
  • @rici It’s GPL. If you want to use a permissive (= non-copyleft) license for your own applications you cannot use readline. – Konrad Rudolph Nov 17 '16 at 18:20
  • @konrad: not strictly true; you just can't bundle it. If you leave weak references and the end user has or is willing to install GNU readline or an API-compatible substitute such as editline, then there is no problem. Anyway, OP did not indicate licencing to be a problem, either in the original question or the response to my question. – rici Nov 17 '16 at 18:42
  • @rici Yes, very strictly true. Virtually all interpretations in the last years (this was different before about 2010) agree on that point: Bundling is irrelevant. Even linkage mode (static/dynamic/what-have-you) is. The relevant part is that you’re using it. – Konrad Rudolph Nov 17 '16 at 18:59

3 Answers3

17

This is an admirable goal I think :-)

Perhaps Linenoise, libedit/editline or tecla would fit the bill?

Of those probably libedit is the most widely used - e.g. postgreqsql client shell and various BSD utilities for Kerberos and ntp (although for the upstream sources it may not be the default line editing library for compilation due the to widespread use of libreadline on Linux). There are a couple of slightly different versions of libedit/editline as you'll see if you read some of those references and do some further research.

Cheers, and good luck with your project.

G. Cito
  • 6,210
  • 3
  • 29
  • 42
  • 1
    Linenoise works just fine to enable functionality in the Perl6 (now Raku) REPL. See: https://course.raku.org/essentials/running-programs/from-repl/ – jubilatious1 Sep 01 '21 at 20:32
  • 1
    @jubilatious1 Awesome news! I havent't been following raku for awhile. I think a raku REPL that mixes the best of [`re.pl`](https://metacpan.org/pod/Devel::REPL), R, Scala, etc. and a "built in" GUI framework that steals ideas from electron, ggplotgui and mojolicoius (!) is inevitable. It is such a fast-to-write language to work with. – G. Cito Sep 03 '21 at 20:30
  • We need you back! Feel free to add your expertise to https://github.com/rakudo/rakudo/issues/4402 and https://github.com/rakudo/rakudo/issues/4196 . Cheers. – jubilatious1 Sep 09 '21 at 16:21
5

There is replxx, a BSD licensed alternative to readline. It works in Linux, BSD, Solaris and Windows. It has support for features you expect from interactive console programs, namely:

  • line editing
  • history
  • syntax highlighting
  • hints
  • UTF-8
  • user defined key bindings (supporting (shift/ctrl)F1 - F12)
  • multi-threaded print
AmokHuginnsson
  • 1,174
  • 10
  • 14
0

I think the modern alternative of GNU Readline is Jupyter Notebook. The idea is that you don't create an executable that links to a line editor library. Instead, you should just provide the kernel and the users can choose their own notebook UI, either CUI, web based GUI, or even an IDE like VS Code.

Yang Bo
  • 3,586
  • 3
  • 22
  • 35