Обсуждение: Tab completion not working on OSX Lion (10.7.3)

On 04/13/2012 10:27 AM, Bryan Hughes wrote:
> Prior to updating my Snow Leopard Mac to OSX Lion (10.7.3), I was able
> to open psql from a terminal and then use "tab complete" to
> auto-complete table or field names (i.e., "select * from [TAB -- list
> of table names]"). Unfortunately, something appears to have changed
> and tab complete now does nothing.
>
> Does anyone know of a fix for this problem?
Not familiar with PostgreSQL on Mac but I believe that tab-complete
requires readline support so perhaps you ended up with a psql without
readline or you are missing some necessary libraries.

Cheers,
Steve

Bryan Hughes <huuuze@gmail.com> writes:
> Prior to updating my Snow Leopard Mac to OSX Lion (10.7.3), I was able to
> open psql from a terminal and then use "tab complete" to auto-complete
> table or field names (i.e., "select * from [TAB -- list of table names]").
> Unfortunately, something appears to have changed and tab complete now does
> nothing.

> Does anyone know of a fix for this problem?

Apple broke this (again, or should I say worse) in their Lion update of
libedit.  There's discussion of that in the PG archives.  On track
record so far, nothing will be done about it before Mountain Lion, and
that version will have an all-new set of bugs instead.

If you're using psql to any significant extent on OS X, I'd recommend
installing GNU libreadline and then building a copy of psql linked to
that.

(Note: /usr/lib/libreadline.dylib is *not* GNU readline, despite the
name; it's merely a symlink to libedit.)

            regards, tom lane

On 04/13/12 12:07 PM, Tom Lane wrote:
> Apple broke this (again, or should I say worse) in their Lion update of
> libedit.

libedit has a long and nasty track record of being quite buggy.   I was
using it briefly on a couple Unix systems we were trying to avoid
gnupollution on and found it was way easy to coredump psql just by
hitting keys too fast.   meh.



--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

John R Pierce <pierce@hogranch.com> writes:
> On 04/13/12 12:07 PM, Tom Lane wrote:
>> Apple broke this (again, or should I say worse) in their Lion update of
>> libedit.

> libedit has a long and nasty track record of being quite buggy.   I was
> using it briefly on a couple Unix systems we were trying to avoid
> gnupollution on and found it was way easy to coredump psql just by
> hitting keys too fast.   meh.

Yeah, to be fair the bug in question is upstream's, not Apple's.
I'm just griping because they seem to grab random snapshots of
upstream's SCM and release them with hardly any testing.  It would
possibly be all right if they didn't then sit on that release for
an entire OS major version cycle :-(

            regards, tom lane

On 04/13/12 1:16 PM, Tom Lane wrote:
> Yeah, to be fair the bug in question is upstream's, not Apple's.
> I'm just griping because they seem to grab random snapshots of
> upstream's SCM and release them with hardly any testing.  It would
> possibly be all right if they didn't then sit on that release for
> an entire OS major version cycle :-(

hey, noone on Apple does any typing of commands, thats so 20th century.



--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

Bryan Hughes <huuuze@gmail.com> writes:
> I now have "libreadline.a" in /usr/local/lib. Assuming that's the goal,
> would you be kind enough to walk me through the next step -- linking that
> lib to psql?

I think it should work to just configure and build postgres the same as
you otherwise would --- I believe Apple's gcc follows the usual
convention of looking in /usr/local first.  You can check the results
with "otool -L psql".  If it mentions /usr/lib/libedit.dylib or
/usr/lib/libreadline.dylib, you still have a dependency on libedit,
else not.

            regards, tom lane