Thread: BUG #12300: ~/.psql_history nonexistent warning on first run

BUG #12300: ~/.psql_history nonexistent warning on first run

From
dlazerka@gmail.com
Date:
The following bug has been logged on the website:

Bug reference:      12300
Logged by:          Dzmitry Lazerka
Email address:      dlazerka@gmail.com
PostgreSQL version: 9.3.5
Operating system:   Linux Mint x64 3.13.0-24-generic #47-Ubuntu
Description:

1. Either install fresh PostgreSQL on fresh OS, or just delete
`~/.psql_history`.
2. Run `~ $ psql` (assuming that permissions are already set up for your
user).
3. type any command;
4. Press Ctrl-D, or type "\q".

OBSERVED: warning
could not save history to file "/home/myuser/.psql_history": No such file or
directory

EXPECTED: info like:
Created "/home/myuser/.psql_history"

Because currently it sounds like it wasn't found, so history is lost
forever. Also, it happens on the very first run, when user hasn't had a
chance to screw up anything yet, but psql already throws errors.

Re: BUG #12300: ~/.psql_history nonexistent warning on first run

From
Tom Lane
Date:
dlazerka@gmail.com writes:
> PostgreSQL version: 9.3.5
> Operating system:   Linux Mint x64 3.13.0-24-generic #47-Ubuntu

> 1. Either install fresh PostgreSQL on fresh OS, or just delete
> `~/.psql_history`.
> 2. Run `~ $ psql` (assuming that permissions are already set up for your
> user).
> 3. type any command;
> 4. Press Ctrl-D, or type "\q".

> OBSERVED: warning
> could not save history to file "/home/myuser/.psql_history": No such file or
> directory

Which readline/history library are you using --- GNU readline, or libedit?
And what version exactly?

FWIW, I do not see this behavior with readline 6.0 on my RHEL6 machine,
nor with the libedit that Apple is shipping in Yosemite (seems to be a
patched copy of libedit 3.0). It wouldn't surprise me a whole lot if it
happens with some other versions of libedit.  There isn't a lot we can do
if it's libedit's fault; that library is enough of a mess, and enough of a
moving target, that we have to be satisfied if it works at all, never mind
cosmetic issues.

            regards, tom lane

Re: BUG #12300: ~/.psql_history nonexistent warning on first run

From
Tom Lane
Date:
Dzmitry Lazerka <dlazerka@gmail.com> writes:
> I have `history` available, but nor `readline`, nor `libedit` available as
> commands in my bash.

That's not particularly relevant, because what we're talking about here is
libraries not shell commands.

Applying ldd to the psql executable might yield something informative.
On my machine for instance I get

        ...
        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003ad8e00000)
        ...

            regards, tom lane

Re: BUG #12300: ~/.psql_history nonexistent warning on first run

From
Dzmitry Lazerka
Date:
Hmm, gotcha, thanks. Maybe those libraries don't deserve to be used by such
a serious project like PostgreSQL if they are such a mess.

I have `history` available, but nor `readline`, nor `libedit` available as
commands in my bash.

`man history` shows "GNU History 6.3 2013 June 27 HISTORY(3)", so it's
probably it, unless my `man` is out-of-date.

Bash version: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)


-----
Best regards,
Dzmitry Lazerka

On Sun, Dec 21, 2014 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> dlazerka@gmail.com writes:
> > PostgreSQL version: 9.3.5
> > Operating system:   Linux Mint x64 3.13.0-24-generic #47-Ubuntu
>
> > 1. Either install fresh PostgreSQL on fresh OS, or just delete
> > `~/.psql_history`.
> > 2. Run `~ $ psql` (assuming that permissions are already set up for your
> > user).
> > 3. type any command;
> > 4. Press Ctrl-D, or type "\q".
>
> > OBSERVED: warning
> > could not save history to file "/home/myuser/.psql_history": No such
> file or
> > directory
>
> Which readline/history library are you using --- GNU readline, or libedit?
> And what version exactly?
>
> FWIW, I do not see this behavior with readline 6.0 on my RHEL6 machine,
> nor with the libedit that Apple is shipping in Yosemite (seems to be a
> patched copy of libedit 3.0). It wouldn't surprise me a whole lot if it
> happens with some other versions of libedit.  There isn't a lot we can do
> if it's libedit's fault; that library is enough of a mess, and enough of a
> moving target, that we have to be satisfied if it works at all, never mind
> cosmetic issues.
>
>                         regards, tom lane
>