Обсуждение: 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 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/