GJgjvc·May 14, 2024Submission
editline – a small line editing library, call compatible with FSF readline
2 points · Open discussiontroglobit
editline
C2017–2024
troglobit / editline
editline
A small replacement for GNU readline() for UNIX
4Distinct people
4Mentions
1Explicit recommenders
411GitHub stars
What to know before exploring
What it is
A small replacement for GNU readline() for UNIX
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
I like this title so much I am finally going to give this shell a try. One thing I notice right away is readline. Could editline also be an option. (There's two "editlines",…
1vuio0pswjnm7 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year4 dated mentions
Observed mentions: 2017-11-10 20:54:46 UTC to 2024-05-14 00:49:25 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
4 sourcesI like this title so much I am finally going to give this shell a try. One thing I notice right away is readline. Could editline also be an option. (There's two "editlines", the NetBSD one and an older one at https://github.com/troglobit/editline) Next thing I notice is the use of ANSI codes by default. Could that be a compile-time option or do we have to edit the source to remove it.
TBH I think the graphical web browser is the current generation's Multics. Something that is overly complex, corporatised, and capable of being replaced by something simpler.
I am not steeped in Kubernetes or its reason for being but it sounds like it is filling a void of shell know-how amongst its audience. Or perhaps it is addressing a common dislike of the shell by some group of developers. I am not a developer and I love the shell.
It is one thing
Read the rest
that generally does not change much from year to year. I can safely create things with it (same way people have made build systems with it) that last forever. These things just keep running from one decade to the next no matter what the current "trends" are. Usually smaller and faster, too.
Lile a small fast configurable line editing facility
Interpreters, e.g., k and q, sometimes have no command line history or editing.
A solution frequently recommended for k and q is rlwrap.
I find rlwrap too big and slow, especially for the tiny, fast k and q interpreters. It feels sluggish.
I have begun experimenting with "lile", a modified version of "ile" which apparently dates back to 1988. I have not seen it discussed anywhere on today's www.
It is small and fast. Custom key commands can be assigned per application using configuration files.
More info:
ftp://ftp7.FreeBSD.org/sites/ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/misc/lile/DESCR
ftp://ftp6.us.freebsd.org/mirror/FreeBSD-Archive/ports/distfiles/lile-2.0.tar.z
ftp://ftp.sra.co.jp/pub/os/NetBSD/NetBSD-current/pkgsrc/misc/lile/patches/patch-aa
Do HN readers have other suggestions?
Below are some familiar options I have explored.
Read the rest
Dates may be wrong.
linenoise (2010)
https://github.com/antirez/linenoise
libtecla (2001)
http://www.astro.caltech.edu/~mcs/tecla/
editline (1992)
https://thrysoee.dk/editline/
editline (1992)
https://github.com/troglobit/editline
readline (1989)
https://tiswww.case.edu/php/chet/readline/rltop.html
Already discussed on HN: GNU readline, BSD editline, rlwrap and linenoise. I suspect enhance and libtecla have been discussed too (alternatives to rlwrap and readline).
For example: https://news.ycombinator.com/item?id=5086837
Both editline and readline are large, too large to be compiled into every program that could benefit from REPL.
The answer to the bloat is linenoise. Great project.
But then there are all the programs that already have the readline bloat compiled in. How to replace it with something smaller? Can this be done?
There is another editline, not NetBSD's editline. It may predate the web, as it was originally distributed via Usenet. I do not recall it ever being discussed on HN. I suspect the original author probably has an HN account.
From Github:
*call compatible with GNU readline*
small size (<30K)
ori
Read the rest
ginally developed for older UNIX and Plan 9
forked from Minix 3, not related to NetBSD editline
does not rely on libtermcap/curses
source: https://github.com/troglobit/editline
socat can function as a replacement for rlwrap, something like:
socat -t0 readline exec:q
where "q" is a program that could benefit from a REPL.
Perceptually I find socat readline exits faster than rlwrap. The later always feels a bit sluggish. Same for libtecla's enhance.
Is there a linenoise-based replacement for rlwrap?