Please report any problems to me (hlub@knoware.nl). (There are now a
lot of packaged versions of rlwrap for all kinds of distros, and many
of their maintainers just fix bugs without even notifying me. The more
upstream a bug is fixed, the more people will profit from it!!)


Whenever you suspect a bug, if possible, reconfigure with ./configure
--enable-debug and run rlwrap with -d option. This will create a file
/tmp/rlwrap.debug that will help me find the problem.

* Installation problems:

---

rlwrap needs the readline library (ftp://ftp.gnu.org/gnu/readline/),
version 4.2 or newer. For .deb or .rpm users: install the readline
-devel- package!

---

Even though rlwrap now uses the excellent pseudo-terminal (pty)
handling code from rxvt, portable programming with ptys is something
of a black art. The configure script tries to guess how ptys have to
be handled on your system, but it may guess wrong. To quote rxvt's
configure script: "if we don't guess right then it's up to the user",
which means that you have to manually edit config.h, and save a copy
of it somewhere, as configure will re-create config.h

---

Andreas Leitgeb wrote:

  "If (on Solaris) configure fails to detect your libreadline, 
  then (temporarily) move the dynamic libs libreadline.so*
  out of sight, and try again. (seems to be a problem in the
  readline-package obtained from sunfreeware.com)"

-- 

After "configure", make wil re-run configure. This is a minor
annoyance, and probably due to my poor understanding of automake. 

* Run-time problems

rlwrap cannot handle prompts that contain control characters.  Any
client that uses color and/or curses will confuse rlwrap (though you
may not notice this until your cursor almost reaches end-of-line)
This may change in future releases (but not by much, cf. the TODO file)

---

readline-4.3 support for multi-byte characters is slightly buggy,
revert to 4.2 or upgrade to 5.0. rlwrap itself doesn't yet handle
multi-byte characters correctly - again you may only notice this 
when the cursor almost reaches end-of-line 

---

Christoffer Dam Bruun reported:

  "I have just installed rlwrap along with readline on Solaris 8 and
  found that rlwrap did not work properly with readline 4.3. After
  linking rlwrap with readline 4.2 it works correctly.

  What happended using readline 4.3 was that an extra prompt would be 
  written after the first letter on a line, e.g. with a sqlplus prompt:
  SQL>
  (now writing select )
  SQL> sSQL> select"

I (HL) have not been able to reproduce this, but there have been a few
more reports about this. In a few cases, the display was even more
garbled, like

  SQL> sSQL> se>SQL> selSQL> sele>SQL> selec> .... 

Remedy: first make sure that your readline headers and runtime
libraries are in sync. May people have a readline-dev package that is
older than their runtime libraries. If this doesn't help: configure
rlwrap with --enable-homegrown-redisplay and recompile.


---
Readline 5.0 has a slight bug where scrolling up through history and
then back again ends on a non-empty line (the first history line, in
fact) There is a patch for bash available that also works for
readline: copy bash30-005.patch to your readline-5.0 source directory
and do 

$  patch < bash30-005.patch 

Ignore complaints about the last hunk, as this is only for bash

---

The -r option feeds the output of the rlwrapped program into the
completion word list. This output is then read into a fixed-size buffer,
which means that words may be split in half when they are unfortunate
enough to end up at the end of this buffer. Thus a few mutilated words
may end up in the completion word list when the rlwrapped program
spews out long chunks of text.

---

The -m option uses the system() (3) library function to call an
external editor. I'm not quite sure how system() handles signals like
TSTP an WINCH (and it is a difficult name to Google for...) Re-sizing
the terminal may confuse the editor

--

Paolo Casaschi reported that his rlwrap failed with the message
  
  rlwrap: error: Could not open slave pty: Permission denied

This turned out to be a problem with /etc/fstab, where the entry for
/dev/pty was:

  none    /dev/pts    devpts  gid=5,mode=20            0 0 

instead of 

  none   /dev/pts     devpts  gid=5,mode=620           0 0
  
which fixed the problem



 
