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

> Conley Owens <cco3@android.com> writes:
>
>> On Mon, Aug 20, 2012 at 7:30 PM, Jeff King <peff@peff.net> wrote:
>>> On Mon, Aug 20, 2012 at 06:28:57PM -0700, Conley Owens wrote:
>>>
>>>> From f64ba3c908b33a2ea5a5ad1f0e5800af76b82ce9 Mon Sep 17 00:00:00 2001
>>>> From: Conley Owens <cco3@android.com>
>>>> 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.
>