Re: [PATCH] Fallback on getpwuid if envar HOME is unset

Conley Owens [off-list ref] writes:

On Mon, Aug 20, 2012 at 7:30 PM, Jeff King [off-list ref] wrote:

quoted

On Mon, Aug 20, 2012 at 06:28:57PM -0700, Conley Owens wrote:

quoted

From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001
From: Conley Owens <redacted>
Date: Mon, 20 Aug 2012 18:23:40 -0700
Subject: [PATCH] Fallback on getpwuid if envar HOME is unset

Please drop these lines from the message body; they are redundant with
your email's headers.

This seems sensible on the surface, but I'm a bit curious: why isn't
$HOME set? And are there any reasons that somebody who has unset HOME
would not want to fallback?  For example, running under Apache, HOME is
often unset when calling CGI programs. Would it make sense for us to
look in ~www-data/.gitconfig in that case?

I think it might, but perhaps I'm wrong.  As another example, upstart strips all
the environment variables, so if you run a job as a particular user, that user's
.gitconfig will not be read unless HOME is specified.

Do you mean upstart as the "replacement init.d mechanism"?  If that
is the case, the responsibility to set up HOME was moved to the
scripts by upstart if they rely on having a sane value in $HOME; I
do not see it as Git's problem, as it is not the only program that
looks at and acts on the value of $HOME [*1*].

Where do shells (e.g. bash and dash) go when you say "cd" without
parameter when $HOME is unset, for example?  I do not think they
magically read from getpwent() and use the value from there to fill
the $HOME's place.  We should follow suit.


[Footnote]

*1* I further have to suspect that enough scripts would be
inconvenienced by such a (mis)feature in upstart that over time the
environment scrubbing may have to be rethought in upstart, and at
that point, this entire discussion would become moot.

On Tue, Aug 21, 2012 at 11:22 AM, Junio C Hamano [off-list ref] wrote:

Conley Owens [off-list ref] writes:

quoted

On Mon, Aug 20, 2012 at 7:30 PM, Jeff King [off-list ref] wrote:

quoted

On Mon, Aug 20, 2012 at 06:28:57PM -0700, Conley Owens wrote:

quoted

From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001
From: Conley Owens <redacted>
Date: Mon, 20 Aug 2012 18:23:40 -0700
Subject: [PATCH] Fallback on getpwuid if envar HOME is unset

Please drop these lines from the message body; they are redundant with
your email's headers.

This seems sensible on the surface, but I'm a bit curious: why isn't
$HOME set? And are there any reasons that somebody who has unset HOME
would not want to fallback?  For example, running under Apache, HOME is
often unset when calling CGI programs. Would it make sense for us to
look in ~www-data/.gitconfig in that case?

I think it might, but perhaps I'm wrong.  As another example, upstart strips all
the environment variables, so if you run a job as a particular user, that user's
.gitconfig will not be read unless HOME is specified.

Do you mean upstart as the "replacement init.d mechanism"?  If that
is the case, the responsibility to set up HOME was moved to the
scripts by upstart if they rely on having a sane value in $HOME; I
do not see it as Git's problem, as it is not the only program that
looks at and acts on the value of $HOME [*1*].

Yes, that's the upstart I'm referring to.  This makes sense.  However, it's a
confusing situation to run into.  Would a warning about an unset $HOME be
appropriate?

Where do shells (e.g. bash and dash) go when you say "cd" without
parameter when $HOME is unset, for example?  I do not think they
magically read from getpwent() and use the value from there to fill
the $HOME's place.  We should follow suit.


[Footnote]

*1* I further have to suspect that enough scripts would be
inconvenienced by such a (mis)feature in upstart that over time the
environment scrubbing may have to be rethought in upstart, and at
that point, this entire discussion would become moot.