[debian-mysql] Bug#550797: mysql history regressions

[Craig Sanders]

Package: mysql-client-5.1
Version: 5.1.39-1

(note: these problem seems common to all 5.1.x versions that i've tried)

i recently upgraded from mysql 5.0 to 5.1 and noticed that mysql history
doesn't work as well, or as usefully, as it used to. the problems
include:

1. when i first ran mysql client after the upgrade, it complete erased
   my previous .mysql_history file.  I lost several useful queries which
   i'll have to recreate next time i need them.

   this is probably due to the switch from using GNU readline to using
   libedit.

2. the .mysql_history file is uglified by escaping various characters (incl.
   space, tab, backslash, etc), with their octal equivalents.  this makes
   it difficult to read and impossible to cut and paste.  there doesn't seem
   to be ANY good reason for doing this.

   for example, this (which lists un-transcoded recordings in mythtv):

select substr(title,1,20) as title,substr(subtitle,1,20) as subtitle,starttime,(filesize/(1024*1024*1024)) as GB from recorded where transcoded = 0 order by starttime; select sum(filesize/(1024*1024*1024)) as GB from recorded where transcoded = 0;

   is stored in .mysql_history as:

select\040substr(title,1,20)\040as\040title,substr(subtitle,1,20)\040as\040subtitle,starttime,(filesize/(1024*1024*1024))\040as\040GB\040from\040recorded\040where\040transcoded\040=\0400\040order\040by\040starttime;\040select\040sum(filesize/(1024*1024*1024))\040as\040GB\040from\040recorded\040where\040transcoded\040=\0400;

   sure, i *can* use sed or perl or whatever to un-escape these
   characters, but why should i have to?

3. ^W erases from the cursor to the beginning of the line, rather than
   just the previous word

4. tab completion seems less useful than it used to be, and certainly
   inadequate. I can't specify it more precisely than that, but it
   doesn't reliably complete field names. e.g. try "select pass<tab>"
   while using the mysql database. it *should* complete that as
   "password", one of the fields in the user table. it doesn't. it does
   nothing. the "SELECT" keyword should have been a clue to the client
   that a fieldname was being completed.

   similarly, "select password from us<tab>" should complete the table
   name "user", but it doesn't - it stops at "use", presumably because
   use is a key word in mysql. should be context sensitive here - nobody
   is ever going to use that keyword there. the only thing they're ever
   going to want to tab complete after the "FROM" keyword is a database
   or table name.

5. history searching doesn't work.  already reported in bug #539748




from googling for "_HiStOrY_V2_", it seems that most if not all of these
problems are due to linking with libedit rather than GNU readline. mysql
needs to be compiled with "--without-readline --without-libedit" to get
the system GNU readline, otherwise it uses the old version of either
libedit or readline which are included with the mysql sources.

this problem was probably introduced with this changelog entry back in
Jan 2007:

mysql-dfsg-5.1 (5.1.14beta-1) experimental; urgency=low
  [...]
  * Replaced --without-readline to --with-libedit to configure options, as
    --without-readline doesn't seem to do the right thing anymore.
 -- Monty Taylor <mordred at inaugust.com>  Wed, 10 Jan 2007 12:59:55 -0800


this needs to be fixed properly. libedit is an inadequate substitute
for GNU readline, and the only reason to use it is if memory/disk usage
is important (e.g. for dash), or if you hate the GPL and prefer BSD
licenses. the bundled (old) gnu readline that comes with mysql source is
preferable to libedit: '--with-readline --without-libedit' should enable
that.

craig

-- 
craig sanders <cas at taz.net.au>