SQLite Forum

Odd CL behaviour

Odd CL behaviour

(1) By Trudge on 2021-07-30 16:07:11 [link] [source]

Funny thing happened on the way to my Mac Terminal window.

Normally when I use sqlite and scroll through the command history, I can move back and forth one word-at-a-time on the previous command by using Alt-left arrow and Alt-right arrow. Today that stopped working and instead of moving the cursor those keys now produced either a 'b' or an 'f' in the line.

So first thing to do is close the Terminal window and open a new one - that restarts bash. Then run sqlite again. Same thing.

So next thing to do is reboot. Did that. Same thing.

So next thing to do is google for an answer. Did that. Nothing helped.

So next thing to do is d/l a new version of sqlite. No new version is available, but grabbed the source code anyway.

Then recompiled it - make install; make. That finally worked.

But now the question is why was that necessary? The executable I have should not have to be re-compiled. But that is what worked.

So fire put out and moving on (using Alt-left arrow / Alt-right arrow). 😎

SQLite version 3.37.0 2021-07-19 14:00:29

(2) By anonymous on 2021-07-30 17:35:20 in reply to 1 [link] [source]

Where does the original executable come from? Did you compile it yourself?

If so, what installation of readline did you link against? From HomeBrew or some other package manager?

In my experience, homebrew often links against versioned paths to the library file, which means that after upgrading your readline, the old executable won't find it any more. (But I guess it should then fail to load rather than run without readline support.)

(5) By Trudge on 2021-07-31 15:02:07 in reply to 2 [link] [source]

If I recall the original executable did come from the sqlite repository, and was not compiled by me. But I have used Homebrew versions prior to this on other versions. But this behaviour came 'out of the blue' after working fine since the d/l.

And I have also had to re-compile various versions to get specific behaviour. Perhaps I should follow the advice of @wyoung and stick with the Homebrew compiles. And if something is needed I can easily compile myself.

Thank you all who responded and provided (as usual) some good instruction and advice.

(3) By Larry Brasfield (larrybr) on 2021-07-30 17:42:16 in reply to 1 [link] [source]

It appears that you had a build of sqlite3 which did not have line editing. If you want to chase this annoyance down, you will need to discover the provenance of the binary sqlite3 that ran before you installed one more to your liking. That might be a chore if the latter displaced the annoying one.

(4) By Warren Young (wyoung) on 2021-07-31 06:22:02 in reply to 1 [source]

The current Mac binaries aren't dynamically linked to either libedit or to libreadline:

$ otool -L ~/Downloads/sqlite-tools-osx-x86-3360000/sqlite3 
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)

Since macOS ships libedit in its stock config, the pre-built binaries should link to that rather than to Readline.

Trudge, another option is to use the Homebrew build of SQLite, which is always up-to-date and brings in Readline as a dependency. The main problem with this is that you then have two sqlite3 binaries on your system, both of which use different history file syntaxes, so bouncing between them can cause you to lose command history as each overwrites the other's output.

(6) By Trudge on 2021-07-31 15:06:58 in reply to 4 [link] [source]

Excellent points and good advice. Thank you. I ran into that situation with the native installation of sqlite3 so have gotten into the habit of renaming mine 'sqlite' and moving it into my PATH. I would be wise to stick with the Homebrew versions and re-compile if needed.