Readline problems

[CRGreathouse]

I'm having trouble with readline and wondered if anyone had similar experiences or could tell me what may be wrong.

When I come to the end of a line, the cursor goes back to the beginning of the same line and overwrites the text. When going back it won't display the displaced text either. And occasionally (typically when dealing with similarly 'long' lines) text will appear on a line that isn't in the edit buffer:
> thisIsFromTheLastCommand1+1
where only the "1+1" is part of the current line and I can't backspace past it.

In this case I'm using Pari

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.3.1 kernel) 64-bit version
           compiled: Jun  2 2009, gcc-4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
                 (readline v5.2 enabled, extended help enabled)

but I imagine the problem is generic.

[CRGreathouse]

I've downloaded and built readline 6.0. I'm curious to see if that fixes the problem.

[CRGreathouse]

6.0 does not fix the problem. Curiously, it's still reported as v. 5.2:

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.3.1 kernel) 64-bit version
           compiled: Jun 18 2009, gcc-4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
                 (readline v5.2 enabled, extended help enabled)

Does this mean I have tow versions of readline on my computer, or just that Pari detects it wrong?

[lfm]

Originally Posted by CRGreathouse

I'm having trouble with readline and wondered if anyone had similar experiences or could tell me what may be wrong.

When I come to the end of a line, the cursor goes back to the beginning of the same line and overwrites the text. When going back it won't display the displaced text either. And occasionally (typically when dealing with similarly 'long' lines) text will appear on a line that isn't in the edit buffer:
> thisIsFromTheLastCommand1+1
where only the "1+1" is part of the current line and I can't backspace past it.

In this case I'm using Pari

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.3.1 kernel) 64-bit version
           compiled: Jun  2 2009, gcc-4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
                 (readline v5.2 enabled, extended help enabled)

but I imagine the problem is generic.

You could try ctrl-r to repaint the line. It maybe doesn't know what column it is starting at so it doesn't handle the wrap to next line right.

[CRGreathouse]

That doesn't work very well for me.

Here's a composite of three screenshots. First shows the problem, second the apparent quick-fix solution with Ctrl+R (though note superfluous text to the right of cursor), third what I see if I go to the beginning of the line. Note the character misalignment.

But ideally I'd have it working without the need for a special key combination at all...

[akruppa]

The behaviour sounds like what bash's readline does when you have changed the window size, but readline still assumes the old screen dimensions. It gets all confused over where a line is supposed to wrap around. Maybe you can fix it by telling readline the number of columns and rows of your screen, maybe via the .inputrc file, or via the LINES and COLUMNS environment variables?

Alex

[CRGreathouse]

Changing LINES and COLUMNS didn't help.

It may be worth mentioning that bash has no such trouble.

[ldesnogu]

Originally Posted by CRGreathouse

6.0 does not fix the problem. Curiously, it's still reported as v. 5.2:

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.3.1 kernel) 64-bit version
           compiled: Jun 18 2009, gcc-4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
                 (readline v5.2 enabled, extended help enabled)

Does this mean I have tow versions of readline on my computer, or just that Pari detects it wrong?

Is readline statically linked with GP/PARI? Check with way:

ldd whatever_it_s_named

If readline.so appears here, you need to point LD_LIBRARY_PATH where your new readline.so is:

export LD_LIBRARY_PATH=/path/to/directory/where/readline/is:${LD_LIBRARY_PATH}

The behavior Alex describes for bash happens when you resize your terminal window while bash is not active (when for instance running a program in foreground from that terminal).

[CRGreathouse]

Originally Posted by ldesnogu

Is readline statically linked with GP/PARI? Check with way:

ldd whatever_it_s_named

If readline.so appears here, you need to point LD_LIBRARY_PATH where your new readline.so is:

export LD_LIBRARY_PATH=/path/to/directory/where/readline/is:${LD_LIBRARY_PATH}

OK, this seemed like it would solve my problem, given that I compiled readline 6.0 but the program said it was using 5.2. So after a merry game of hiding files from Configure, since the hint --with-readline=/usr/local/lib wasn't enough, I managed to get it to compile like so:

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.3.1 kernel) 64-bit version
           compiled: Jun 20 2009, gcc-4.3.3 (Ubuntu 4.3.3-5ubuntu4) 
                 (readline v6.0 enabled, extended help enabled)

Unfortunately, this seems to have just the same problem. Configure results:

Configuring pari-2.4.3 (DEVELOPMENT VERSION) 
Checking echo to see how to suppress newlines...
...using \c
Looking for some tools first ...
...ld is /usr/bin/ld
...zcat is /bin/zcat
...gzip is /bin/gzip
...ranlib is /usr/bin/ranlib
...perl is /usr/bin/perl
Looking for the compilers ...
...cc is /usr/bin/cc
...gcc is /usr/bin/gcc
GNU compiler version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
Given the previous choices, sizeof(long) is 8 chars.
The internal word representation of a double is not needed (64bit).
==========================================================================
Building for: amd64 running linux (x86-64/GMP kernel) 64-bit version
==========================================================================
C compiler is          /usr/bin/gcc -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer    -fPIC
Executable linker is   /usr/bin/gcc  -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer    -Wl,--export-dynamic 
Dynamic Lib linker is  /usr/bin/gcc  -shared  $(CFLAGS) $(DLCFLAGS) -Wl,-shared,-soname=$(LIBPARI_SONAME)
Looking in C lib for some symbols...
...I did not find exp2.
...I did not find log2.
...Found strftime.
...Found getrusage.
...Found sigaction.
...Found TIOCGWINSZ.
...Found getrlimit.
...Found stat.
...Found vsnprintf.
...Found waitpid.
...Found setsid.
...Found getenv.
...Found isatty.
...I did not find dlopen.
Try again, with -ldl this time...
...Found dlopen.
Checking for optional libraries and headers...
...Found libgmp in /usr/local/lib
...Found gmp header in /usr/local/include
Using GNU MP, version 4.3.1
...Found libX11 in /usr/lib
...Found X11 header files in /usr/include/X11
Hi-Res Graphics: X11
...Found libreadline in /usr/local/lib
...Found readline header in /usr/local/include/readline
...Found history header in /usr/local/include/readline
...Found libncurses in /usr/lib64
...Library ncurses needed by readline
Using GNU readline, version 6.0
Installation prefix ? [/usr/local]
...for architecture-independent files (share-prefix) ? [/usr/local/share]
Installation directories for:
...executables (gp, gphelp) ? [/usr/local/bin]
...libraries (libpari) ? [/usr/local/lib]
...include files ? [/usr/local/include]
...manual pages ? [/usr/local/share/man/man1]
...other system-dependent data ? [/usr/local/lib/pari]
...other system-independent data ? [/usr/local/share/pari]
Default is dynamic executable and shared library
==========================================================================
Extracting examples/Makefile.linux-x86_64
Extracting Olinux-x86_64/Makefile
Extracting Olinux-x86_64/../Odos/paricfg.h
Extracting Olinux-x86_64/paricfg.h
Extracting Makefile
Extracting scripts and macros
...in doc
...in misc
==========================================================================
Shall we try to build pari 2.4.3 (development) now (y/n)? [n]
Ok. Type "make install" when you are ready
Bye !

[lfm]

Originally Posted by CRGreathouse

I'm having trouble with readline and wondered if anyone had similar experiences or could tell me what may be wrong.

What terminal program are you using? Try the plain old xterm, it could be a bug in the terminal program's handling of the escape sequences.

[CRGreathouse]

Nope, it still fails even in xterm.