Thread: psql trerminal behaviour

psql trerminal behaviour

From
"Tim Joyce"
Date:
Hi,

i am having problems in psql getting my arror and delete keys to work!  Has
anyone else experienced this?

Yesterday I installed postgres from the redhat rpms, and psql arrow keys
worked fine.  today (for various reasons) i installed postgres from the
sources, and the arrow keys just return rubbish, so i think it's probably
not my terminal emulator (teraterm on windows nt).

I have seen this behavious on other boxes we run (basically some work and
some don't)

any ideas?

btw, is the htdig archive search working for this mailing list?

tia for help

timj




Re: [INTERFACES] psql trerminal behaviour

From
Thomas Lockhart
Date:
> i am having problems in psql getting my arror and delete keys to work!  Has
> anyone else experienced this?
> Yesterday I installed postgres from the redhat rpms, and psql arrow keys
> worked fine.  today (for various reasons) i installed postgres from the
> sources, and the arrow keys just return rubbish, so i think it's probably
> not my terminal emulator (teraterm on windows nt).
> I have seen this behavious on other boxes we run (basically some work and
> some don't)

Your ./configure step isn't finding readline and history. They are
located in /usr/{include,lib} on my RH5.2 box and they are found
automatically for me.
                      - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [INTERFACES] psql trerminal behaviour

From
"Tim Joyce"
Date:
> > i am having problems in psql getting my arror and delete keys to work!
Has
> > anyone else experienced this?
> > Yesterday I installed postgres from the redhat rpms, and psql arrow keys
> > worked fine.  today (for various reasons) i installed postgres from the
> > sources, and the arrow keys just return rubbish, so i think it's
probably
> > not my terminal emulator (teraterm on windows nt).
> > I have seen this behavious on other boxes we run (basically some work
and
> > some don't)
>
> Your ./configure step isn't finding readline and history. They are
> located in /usr/{include,lib} on my RH5.2 box and they are found
> automatically for me.
>

I have check config.log and can't see anything wrong.  Is there a way to fix
this without rebuilding?  Below it the output from config.log, if you have
time to look at it :)

I have the following files in /usr/lib/:

/usr/lib/libhistory.so.3.0
/usr/lib/libhistory.so.3
/usr/lib/libreadline.so.3.0
/usr/lib/libreadline.so.3

Thanks very much for your help

timj



This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:597: checking host system type
configure:693: checking setting template to
configure:819: checking setting USE_LOCALE
configure:834: checking setting CYR_RECODE
configure:849: checking setting MULTIBYTE
configure:871: checking setting DEF_PGPORT
configure:889: checking setting DEF_MAXBACKENDS
configure:907: checking setting USE_TCL
configure:959: checking setting USE_PERL
configure:976: checking setting USE_ODBC
configure:1025: checking setting ASSERT CHECKING
configure:1056: checking for gcc
configure:1169: checking whether the C compiler (gcc -O2 ) works
configure:1185: gcc -o conftest -O2   conftest.c  1>&5
configure:1211: checking whether the C compiler (gcc -O2 ) is a
cross-compiler
configure:1216: checking whether we are using GNU C
configure:1244: checking whether gcc accepts -g
configure:1276: checking how to run the C preprocessor
configure:1357: checking whether gcc needs -traditional
configure:1482: checking for c++
configure:1514: checking whether the C++ compiler (c++   ) works
configure:1530: c++ -o conftest      conftest.C  1>&5
configure:1556: checking whether the C++ compiler (c++   ) is a
cross-compiler
configure:1561: checking whether we are using GNU C++
configure:1589: checking whether c++ accepts -g
configure:1645: checking for a BSD compatible install
configure:1733: checking for flex
configure:1767: checking for yywrap in -ll
configure:1809: checking whether ln -s works
configure:1830: checking whether make sets ${MAKE}
configure:1859: checking for ranlib
configure:1889: checking for find
configure:1924: checking for tar
configure:1959: checking for split
configure:1994: checking for etags
configure:2029: checking for xargs
configure:2064: checking for ipcs
configure:2099: checking for ipcrm
configure:2136: checking for trbsd
configure:2177: checking for gzcat
configure:2234: checking for bison
configure:2315: checking for main in -lsfio
configure:2359: checking for main in -lncurses
configure:2359: checking for main in -lcurses
configure:2396: checking for main in -ltermcap
configure:2439: checking for main in -lhistory
configure:2482: checking for main in -lreadline
configure:2525: checking for write_history in -lreadline
configure:2570: checking for main in -lbsd
configure:2614: checking for main in -lm
configure:2657: checking for main in -ldl
configure:2700: checking for main in -lsocket
configure:2743: checking for main in -lnsl
configure:2786: checking for main in -lipc
configure:2829: checking for main in -lIPC
configure:2872: checking for main in -llc
configure:2915: checking for main in -ldld
configure:2958: checking for main in -lln
configure:3001: checking for main in -lld
configure:3044: checking for main in -lcompat
configure:3087: checking for main in -lBSD
configure:3130: checking for main in -lcrypt
configure:3173: checking for main in -lgen
configure:3216: checking for main in -lPW
configure:3260: checking for ANSI C header files
configure:3364: checking for sys/wait.h that is POSIX.1 compatible
configure:3409: checking for arpa/inet.h
configure:3449: checking for crypt.h
configure:3489: checking for dld.h
configure:3529: checking for endian.h
configure:3569: checking for float.h
configure:3609: checking for fp_class.h
configure:3649: checking for getopt.h
configure:3689: checking for history.h
configure:3729: checking for ieeefp.h
configure:3769: checking for limits.h
configure:3809: checking for netdb.h
configure:3849: checking for netinet/in.h
configure:3889: checking for readline.h
configure:3929: checking for readline/history.h
configure:3969: checking for readline/readline.h
configure:4009: checking for sys/select.h
configure:4049: checking for termios.h
configure:4089: checking for unistd.h
configure:4129: checking for values.h
configure:4169: checking for sys/param.h
configure:4169: checking for pwd.h
configure:4207: checking for working const
configure:4282: checking for inline
configure:4324: checking for preprocessor stringizing operator
configure:4359: checking for uid_t in sys/types.h
configure:4393: checking for mode_t
configure:4426: checking for off_t
configure:4459: checking for size_t
configure:4492: checking whether time.h and sys/time.h may both be included
configure:4527: checking whether struct tm is in sys/time.h or time.h
configure:4561: checking for tm_zone in struct tm
configure:4632: checking for signed types
configure:4641: gcc -c -O2   conftest.c 1>&5
configure:4656: checking for volatile
configure:4665: gcc -c -O2   conftest.c 1>&5
configure:4680: checking for type of last arg to accept
configure:4692: gcc -c -O2   conftest.c 1>&5
configure:4710: checking for int timezone
configure:4719: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure:4734: checking for gettimeofday args
configure:4743: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure:4758: checking for union semun
configure:4769: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure: In function `main':
configure:4765: storage size of `semun' isn't known
configure: failed program was:
#line 4760 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
int main() {
union semun semun;
; return 0; }
configure:4784: checking for fcntl(F_SETLK)
configure:4796: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure: In function `main':
configure:4790: `SEEK_SET' undeclared (first use in this function)
configure:4790: (Each undeclared identifier is reported only once
configure:4790: for each function it appears in.)
configure: failed program was:
#line 4786 "configure"
#include "confdefs.h"
#include <fcntl.h>
int main() {
struct flock lck;     lck.l_whence = SEEK_SET; lck.l_start = lck.l_len = 0;     lck.l_type = F_WRLCK;     fcntl(0,
F_SETLK,&lck);
 
; return 0; }
configure:4811: checking for 8-bit clean memcmp
configure:4847: checking return type of signal handlers
configure:4888: checking for vprintf
configure:4995: checking for memmove
configure:4995: checking for sigsetjmp
configure:4995: checking for sysconf
configure:5050: checking for sigprocmask
configure:5050: checking for waitpid
configure:5050: checking for setsid
configure:5050: checking for fcvt
configure:5105: checking for fpclass
configure:5105: checking for fp_class
configure:5105: checking for fp_class_d
configure:5105: checking for class
configure:5159: checking for snprintf
configure:5211: checking for vsnprintf
configure:5264: checking for isinf
configure:5301: checking for getrusage
configure:5354: checking for srandom
configure:5407: checking for gethostname
configure:5460: checking for random
configure:5513: checking for inet_aton
configure:5566: checking for strerror
configure:5620: checking for strdup
configure:5673: checking for strtol
configure:5726: checking for strtoul
configure:5779: checking for strcasecmp
configure:5832: checking for cbrt
configure:5938: checking for rint
configure:6035: checking whether 'long int' is 64 bits
configure:6068: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure: failed program was:
#line 6040 "configure"
#include "confdefs.h"
typedef long int int64;

/* These are globals to discourage the compiler from folding all the* arithmetic tests down to compile-time
constants.*/
int64 a = 20000001;
int64 b = 40000005;

int does_int64_work()
{ int64 c,d;
 if (sizeof(int64) != 8)   return 0;   /* doesn't look like the right size */
 /* Do perfunctory checks to see if 64-bit arithmetic seems to work */ c = a * b; d = (c + b) / b; if (d != a+1)
return0; return 1;
 
}
main() { exit(! does_int64_work());
}
configure:6089: checking whether 'long long int' is 64 bits
configure:6122: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure:6145: checking whether snprintf handles 'long long int' as %lld
configure:6181: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure:6270: checking alignment of short
configure:6310: checking alignment of int
configure:6350: checking alignment of long
configure:6391: checking alignment of long long int
configure:6432: checking alignment of double
configure:6494: checking for POSIX signal interface
configure:6506: gcc -o conftest -O2   conftest.c -lcrypt -lnsl -ldl -lm -lbsd  1>&5
configure:6530: checking for tclsh




Re: [INTERFACES] psql trerminal behaviour

From
Thomas Lockhart
Date:
> > > i am having problems in psql getting my arror and delete keys to work!
> > Your ./configure step isn't finding readline and history.
> I have check config.log and can't see anything wrong.  Is there a way to fix
> this without rebuilding?

I doubt that you can fix it without rebuilding, and I'm not certain
what parts you would need to rebuild so it's time for "make clean
install". But first, you have to rerun configure and get it
recognizing that readline/history are available.

> I have the following files in /usr/lib/:
> /usr/lib/libhistory.so.3.0
> /usr/lib/libhistory.so.3
> /usr/lib/libreadline.so.3.0
> /usr/lib/libreadline.so.3

That's good. It looks like the test is also for readline.h and
history.h, which on my machine are in /usr/include/readline/. Here is
an grep from my config.cache:

[postgres@golem src]$ grep -i readline config.cache
config.cache:ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
config.cache:ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
config.cache:ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
config.cache:ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
config.cache:ac_cv_lib_readline_write_history=${ac_cv_lib_readline_write_history='yes'}

I'm pretty sure that other folks can help you with more details. Good
luck.
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [INTERFACES] psql trerminal behaviour

From
"Tim Joyce"
Date:
Thomas,

thanks loads for the help.

what i did was:

rpm -Uvh readline-devel-2.2.1-5.i386.rpm

rm src/config.cache
make clean
make
make install

and it works.

i think that the postgres build should check more thoroughly that
/usr/include/readline/*.h exists and not let you make with out it, as pgsql
is quite unusable without arrow and del keys.

thanks again

Cheers

Tim Joyce
Chief Enthusiast
tim@hoop.co.uk
HOOP Ltd
http://www.hoop.co.uk
01202 251 816

HOOP is proud to be a member of the Paneris community (www.paneris.co.uk)


----- Original Message -----
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
To: Tim Joyce <tim@hoop.co.uk>
Cc: <pgsql-interfaces@postgreSQL.org>
Sent: 28 September 1999 14:55
Subject: Re: [INTERFACES] psql trerminal behaviour


> > > > i am having problems in psql getting my arror and delete keys to
work!
> > > Your ./configure step isn't finding readline and history.
> > I have check config.log and can't see anything wrong.  Is there a way to
fix
> > this without rebuilding?
>
> I doubt that you can fix it without rebuilding, and I'm not certain
> what parts you would need to rebuild so it's time for "make clean
> install". But first, you have to rerun configure and get it
> recognizing that readline/history are available.
>
> > I have the following files in /usr/lib/:
> > /usr/lib/libhistory.so.3.0
> > /usr/lib/libhistory.so.3
> > /usr/lib/libreadline.so.3.0
> > /usr/lib/libreadline.so.3
>
> That's good. It looks like the test is also for readline.h and
> history.h, which on my machine are in /usr/include/readline/. Here is
> an grep from my config.cache:
>
> [postgres@golem src]$ grep -i readline config.cache
> config.cache:ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
>
config.cache:ac_cv_header_readline_history_h=${ac_cv_header_readline_history
_h='yes'}
>
config.cache:ac_cv_header_readline_readline_h=${ac_cv_header_readline_readli
ne_h='yes'}
> config.cache:ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
>
config.cache:ac_cv_lib_readline_write_history=${ac_cv_lib_readline_write_his
tory='yes'}
>
> I'm pretty sure that other folks can help you with more details. Good
> luck.
>
>                     - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California



Re: [INTERFACES] psql trerminal behaviour

From
Thomas Lockhart
Date:
> i think that the postgres build should check more thoroughly that
> /usr/include/readline/*.h exists and not let you make with out it, as pgsql
> is quite unusable without arrow and del keys.

Yes, they help a lot. But we support over two dozen platforms, and not
all have readline/history installed. Just like yours, until you put in
another rpm ;)
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [INTERFACES] psql trerminal behaviour

From
Tom Lane
Date:
"Tim Joyce" <tim@hoop.co.uk> writes:
> i think that the postgres build should check more thoroughly that
> /usr/include/readline/*.h exists and not let you make with out it,

That cure would be a lot worse than the disease!

> as pgsql is quite unusable without arrow and del keys.

If you don't have readline installed, then you're not used to using it,
so I doubt you will consider psql "unusable" without it.  Postgres is
already a pain to install; adding more required prerequisite packages
would make it worse...
        regards, tom lane


Re: [INTERFACES] psql trerminal behaviour

From
"Moray McConnachie"
Date:
----- Original Message -----

> "Tim Joyce" <tim@hoop.co.uk> writes:
> > i think that the postgres build should check more thoroughly that
> > /usr/include/readline/*.h exists and not let you make with out it,
>
> That cure would be a lot worse than the disease!

Agreed.

> > as pgsql is quite unusable without arrow and del keys.
>
> If you don't have readline installed, then you're not used to using
it,
> so I doubt you will consider psql "unusable" without it.  Postgres
is
> already a pain to install; adding more required prerequisite
packages
> would make it worse...

As I understand it, Postgres installation requires you not only to
have readline installed, but to have the readline header-files
installed. Many people may have the readline libraries installed, but
not the headers, e.g, under RedHat 6.0, where you would need to
install not only readline-x.y.rpm (installed by default), but
readline-devel-x.y.rpm, which is not installed by default, IIRC. Might
it be worth sticking something like this on the install FAQ?
----------------------------------------------------------------------
----------------
Moray.McConnachie@computing-services.oxford.ac.uk



Re: [INTERFACES] psql trerminal behaviour

From
Tom Lane
Date:
"Moray McConnachie" <moray.mcconnachie@computing-services.oxford.ac.uk> writes:
> As I understand it, Postgres installation requires you not only to
> have readline installed, but to have the readline header-files
> installed.

Yes; you can hardly build a readline client app from source without 'em.

> Many people may have the readline libraries installed, but
> not the headers, e.g, under RedHat 6.0, where you would need to
> install not only readline-x.y.rpm (installed by default), but
> readline-devel-x.y.rpm, which is not installed by default, IIRC. Might
> it be worth sticking something like this on the install FAQ?

Hmm, good point.  I think you are right, this ought to be pointed out
somewhere in our docs.

(I'd say this is a mispackaging of readline, BTW: installed headers
belong with the library, not with the sources.  By that logic a
non-devel RH system would ship with an empty /usr/include tree and you
couldn't compile *anything*.  But I doubt RH cares what I think...)
        regards, tom lane


Re: [INTERFACES] psql trerminal behaviour

From
Thomas Lockhart
Date:
> As I understand it, Postgres installation requires you not only to
> have readline installed, but to have the readline header-files
> installed. Many people may have the readline libraries installed, but
> not the headers, e.g, under RedHat 6.0, where you would need to
> install not only readline-x.y.rpm (installed by default), but
> readline-devel-x.y.rpm, which is not installed by default, IIRC. Might
> it be worth sticking something like this on the install FAQ?

Perhaps this could go in the Linux FAQ? Send patches...
                  - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [INTERFACES] psql trerminal behaviour

From
eem21@cam.ac.uk
Date:
On 29 Sep, Tom Lane wrote:

> (I'd say this is a mispackaging of readline, BTW: installed headers
> belong with the library, not with the sources.  By that logic a
> non-devel RH system would ship with an empty /usr/include tree and you
> couldn't compile *anything*.  But I doubt RH cares what I think...)

I think that's what they're aiming at - a distribution with which Joe
User doesn't have to compile anything (he lets somebody else do it). 
By extension, if he doesn't want to compile anything, then he doesn't
want the header files on there either.  I think that's the way these
distributions should be.

Ewan Mellor.