Is my home $HOME or is it getpwent()->pw_dir ?
Hi,
I sometimes do some testing as nobody, on a distro where
getpwent(nobody)->pw_dir is a directory that nobody can't write.
So I end up setting $HOME to a directory that, um, is writable.
When I start psql, strace shows $HOME being honored when looking
for .terminfo and .inputrc, and getpwent()->pw_dir being used
to look for .pgpass, .psqlrc, and .psql_history, which of course
aren't there.
I'm sure the .terminfo and .inputrc lookups are being done by library code.
In my experience, it seems traditionally unixy to let $HOME take precedence.
Maybe things that are pointedly cross-platform are more likely to rely
on the getpwent lookup. I run into the same issue with Java, which is
pointedly cross-platform.
But there, I can alias java to java -Duser.home="$HOME" and all is well.
Would a patch be acceptable for psql to allow such an option
on the command line? I assume that would be more acceptable than
just changing the default behavior.
And if so, would it be preferable to add a whole new option for it,
(--home ?) or, analogously to the way java works, just to add a
HOME variable so it can be set on the command line with -v ?
Or would a name like HOME pose too much risk that somebody is using
such a variable in psql scripts for unrelated purposes?
In a moment of hopefulness I tried \set and looked to see if such
a thing already exists, but I didn't see it. I see that I can set
a HISTFILE variable (or set PSQL_HISTORY in the environment),
and can set PSQLRC in the environment (but not as a variable),
and nothing can set the .pgpass location. One HOME variable could
take care of all three in one foop.
(Or could it? Perhaps .pgpass is handled in libpq at a layer unaware
of psql variables? But maybe the variable could have a modify event
that alerts libpq.)
Regards,
-Chap
On 12/18/21 15:57, Chapman Flack wrote:
I see that I can set
a HISTFILE variable (or set PSQL_HISTORY in the environment),
and can set PSQLRC in the environment (but not as a variable),
and nothing can set the .pgpass location
well, not in the psql docs, but in the environment variable section
for libpq I do see a PGPASSFILE.
-C
On Sat, Dec 18, 2021 at 2:07 PM Chapman Flack <chap@anastigmatix.net> wrote:
On 12/18/21 15:57, Chapman Flack wrote:
I see that I can set
a HISTFILE variable (or set PSQL_HISTORY in the environment),
and can set PSQLRC in the environment (but not as a variable),
and nothing can set the .pgpass locationwell, not in the psql docs, but in the environment variable section
for libpq I do see a PGPASSFILE.
psql docs saith:
"This utility, like most other PostgreSQL utilities, also uses the
environment variables supported by libpq (see Section 34.15)."
David J.
On 12/18/21 16:16, David G. Johnston wrote:
psql docs saith:
"This utility, like most other PostgreSQL utilities, also uses the
environment variables supported by libpq (see Section 34.15)."
I'm sure that's adequate as far as that goes. I just happened to miss it
when composing the longer email (and then I just thought "I bet there are
environment variables supported by libpq" and looked there).
Regards,
-Chap
On 18.12.21 21:57, Chapman Flack wrote:
I sometimes do some testing as nobody, on a distro where
getpwent(nobody)->pw_dir is a directory that nobody can't write.
So I end up setting $HOME to a directory that, um, is writable.When I start psql, strace shows $HOME being honored when looking
for .terminfo and .inputrc, and getpwent()->pw_dir being used
to look for .pgpass, .psqlrc, and .psql_history, which of course
aren't there.I'm sure the .terminfo and .inputrc lookups are being done by library code.
In my experience, it seems traditionally unixy to let $HOME take precedence.
See this patch: https://commitfest.postgresql.org/36/3362/