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
