2016-09-20 18:35 GMT+02:00, Tom Lane <t...@sss.pgh.pa.us>:
> Rudolf Gavlas <r.stu...@googlemail.com> writes:
>> The usage of HOME environment variable (if set) is IMO the right,
>> standard and faster way to get_home_path().
> Can you provide some evidence for that claim?  I can believe "faster"
> but the rest sounds like wishful thinking.

1) NetBSD glob(3)
HOME  If defined, used as the home directory of the current user in
tilde expansions.


3) less

4) NetBSD sh(1)
HOME  Set automatically by login(1) from the user's login directory in
the password file (passwd(5)).  This environment variable also
functions as the default argument for the cd built-in.

5) bash(1) (version 4.3.39)
Shell Variables
The following variables are used by the shell.  In some cases, bash
assigns a default value to a variable; these cases are noted below.
HOME   The home directory of the current user; the default argument
for the cd builtin command.  The value of this variable is also used
when performing tilde expansion.

6) OpenLDAP

I've just grabbed what I have at hand, the list could go on ...

>> I work in an environment, where servers are administered by people
>> with different user names and identical uid (0).
> I think what you have there is an incredibly badly-designed system that
> can be expected to break outside software (eg, Postgres).  If we take
> this patch, what's to stop someone from complaining that we broke *their*
> badly-designed system that abuses the HOME variable?  I'm pretty hesitant
> to touch code that's worked the same way for a decade or two on such a
> basis.

I don't think this system is incredibly bad. But that's off-topic.

If you think that using the value of HOME variable as the user's home
directory is bad idea, I won't argue with that, I've already expressed
my opinion. What is the real problem here is using home directory of a
user A as a home directory for user B. That's clearly a bug and if you
want to solve it without using HOME, I am fine with that.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to