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