6999161a2a
readline turns out to be a bit of a stumbling block for the project to
move gdbsupport (and then gdbserver) to the top-level.
The issue is that readline headers are intended to be included with
names like "readline/readline.h". To support this, gdb effectively
adds a -I option pointing to the top-level source directory -- but,
importantly, this option is not used when the system readline is used.
For gdbsupport, a -I option like this would always be needed, but that
in turn would break the system readline case. This was PR build/17077,
fixed in commit a8a5dbcab8.
Previously, we had discussed this on the gdb-patches list in terms of
removing readline from the tree
https://sourceware.org/ml/gdb-patches/2019-09/msg00317.html
However, Eli expressed some concerns, and Joel did as well (off-list).
Given those concerns, and the fact that a patch-free local readline is
relatively new in gdb (it was locally patched for years), I changed my
mind and decided to handle this situation by moving the readline
sources down a level.
That is, upstream readline is now in readline/readline, and the
top-level readline directory just contains the minimal configury
needed to build that.
This fixes the problem because, when gdb unconditionally adds a
-I$(top_srcdir), this will not find readline headers. A separate -I
will be needed instead, which is exactly what's needed for
--with-system-readline.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
gdb/doc/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
readline/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
Move old contents to readline/ subdirectory.
* aclocal.m4, configure, configure.ac, .gitignore, Makefile.am,
Makefile.in, README: New files.
Change-Id: Ice156a2ee09ea68722b48f64d97146d7428ea9e4
79 lines
2.8 KiB
Plaintext
79 lines
2.8 KiB
Plaintext
rlfe (ReadLine Front-End) is a "universal wrapper" around readline.
|
|
You specify an interactive program to run (typically a shell), and
|
|
readline is used to edit input lines.
|
|
|
|
There are other such front-ends; what distinguishes this one is that
|
|
it monitors the state of the inferior pty, and if the inferior program
|
|
switches its terminal to raw mode, then rlfe passes your characters
|
|
through directly. This basically means you can run your entire
|
|
session (including bash and terminal-mode emacs) under rlfe.
|
|
|
|
FEATURES
|
|
|
|
* Can use all readline commands (and history) in commands that
|
|
read input lines in "canonical mode" - even 'cat'!
|
|
|
|
* Automatically switches between "readline-editing mode" and "raw mode"
|
|
depending on the terminal mode. If the inferior program invokes
|
|
readline itself, it will do its own line editing. (The inferior
|
|
readline will not know about rlfe, and it will have its own history.)
|
|
You can even run programs like 'emavs -nw' and 'vi' under rlfe.
|
|
The goal is you could leave rlfe always on without even knowing
|
|
about it. (We're not quite there, but it works tolerably well.)
|
|
|
|
* The input line (after any prompt) is changed to bold-face.
|
|
|
|
INSTALL
|
|
|
|
The usual: ./configure && make && make install
|
|
|
|
Note so far rlfe has only been tested on GNU Linux (Fedora Core 2)
|
|
and Mac OS X (10.3).
|
|
|
|
This assumes readline header files and libraries are in the default
|
|
places. If not, you can create a link named readline pointing to the
|
|
readline sources. To link with libreadline.a and libhistory.a
|
|
you can copy or link them, or add LDFLAGS='-/path/to/readline' to
|
|
the make command-line.
|
|
|
|
USAGE
|
|
|
|
Just run it. That by default runs bash. You can run some other
|
|
command by giving it as command-line arguments.
|
|
|
|
There are a few tweaks: -h allows you to name the history file,
|
|
and -s allows you to specify its size. It default to "emacs" mode,
|
|
but if the the environment variable EDITOR is set to "vi" that
|
|
mode is chosen.
|
|
|
|
ISSUES
|
|
|
|
* The mode switching depends on the terminal mode set by the inferior
|
|
program. Thus ssh/telnet/screen-type programs will typically be in
|
|
raw mode, so rlfe won't be much use, even if remote programs run in
|
|
canonical mode. The work-around is to run rlfe on the remote end.
|
|
|
|
* Echo supression and prompt recognition are somewhat fragile.
|
|
(A protocol so that the o/s tty code can reliably communicate its
|
|
state to rlfe could solve this problem, and the previous one.)
|
|
|
|
* See the intro to rlfe.c for more notes.
|
|
|
|
* Assumes a VT100-compatible terminal, though that could be generalized
|
|
if anybody cares.
|
|
|
|
* Requires ncurses.
|
|
|
|
* It would be useful to integrate rlfe's logic in a terminal emulator.
|
|
That would make it easier to reposition the edit position with a mouse,
|
|
integrate cut-and-paste with the system clipboard, and more robustly
|
|
handle escape sequence and multi-byte characters more robustly.
|
|
|
|
AUTHOR
|
|
|
|
Per Bothner <per@bothner.com>
|
|
|
|
LICENSE
|
|
|
|
GPL.
|