[GRASS-user] readline issues

[Glynn Clements]

Jerry Nelson wrote:

> I've been commenting the with-readline=yes option out of my grass6.3
> configure command (run on a CentOS/Redhat distro) because it can't seem to
> find the library, even though I have told it where it is. But my question is
> whether and why this is necessary. My understanding is that readline is what
> makes command completion possible (in the shell, type a letter and readline
> will try to complete the word for you). It may also be what makes it
> possible to use the up and down keys to scroll through previous commands. In
> the grass command window, I can get previous commands, but I don't get
> command completion. I tried downloading the grass addon grass-complete but
> was told my bash was too new for it.
>  
> Any suggestions appreciated!

The only part of GRASS which uses readline is r.mapcalc. If readline
is enabled, you can use its history/editing facilities when entering
r.mapcalc expressions on stdin.

The GRASS shell is just your normal shell (e.g. bash) with a few
environment variables set. Command completion should work for GRASS
commands as with other commands. ISTR that grass-complete adds more
specific functionality (completing map names?).

Problems with the configure script not "finding" the readline library
are invariably because it requires one of the terminal libraries
(libtermcap, libtinfo or lib[n]curses) but doesn't list the library as
a dependency.

Consequently, when configure tries to link a test program (which is
how it checks for libraries) against readline, it fails due to
unresolved symbols (typically tgetent, tgetstr etc). You can confirm
this by examining the end of the config.log file.

Normally, we would just add a list of optional libraries to the
configure check, so that it first tests readline alone, then tests
readline + libtermcap/libtinfo/lib[n]curses. E.g. for TIFF, in
addition to libtiff, it also tries all possible combinations of the
JPEG, zlib and math libraries until either one combination succeeds or
all eight combinations have failed.

The problem here is that there are at least three common libraries
(counting libcurses/libncurses as one library) which may all provide
the same set of functions (the "termcap" API: tgetent() etc), and
there is no obvious "right" choice. It's quite possible that multiple
options will succeed, at least in terms of linking.

However, using different libraries may produce different results. E.g. 
one library might use the termcap database while another uses the
terminfo database; some libraries might honour the TERMCAP and/or
TERMINFO environment variables, some might not.

If we pick the wrong one, the configure test will succeed but any
program which uses it might not actually run. As r.mapcalc is a
critical module (a lot of scripts use it internally), ensuring that it
works has a higher priority than enabling interactive line editing.

-- 
Glynn Clements <glynn at gclements.plus.com>