Re: [PATCH] Allow overriding the home directory via the HOME variable

[Johannes Schindelin <Johannes dot Schindelin at gmx dot de>]

Hi Corinna,

On Fri, 23 Oct 2015, Corinna Vinschen wrote:

> On Oct 23 11:10, Corinna Vinschen wrote:
> > On Oct 22 17:38, Johannes Schindelin wrote:
> > > 
> > > On Wed, 21 Oct 2015, Corinna Vinschen wrote:
> > > 
> > > > On Sep 16 15:06, Johannes Schindelin wrote:
> > > > > 	* uinfo.cc (cygheap_pwdgrp::get_home): Offer an option in
> > > > > 	nsswitch.conf that let's the environment variable HOME (or
> > > > > 	HOMEDRIVE & HOMEPATH, or USERPROFILE) define the home
> > > > > 	directory.
> > > > > 
> > > > > 	* ntsec.xml: Document the `env` schema.
> > > > > 
> > > > > Detailed comments:
> > > > > 
> > > > > In the context of Git for Windows, it is a well-established technique
> > > > > to let the `$HOME` variable define where the current user's home
> > > > > directory is, falling back to `$HOMEDRIVE$HOMEPATH` and `$USERPROFILE`.
> > > > > 
> > > > > The idea is that we want to share user-specific settings between
> > > > > programs, whether they be Cygwin, MSys2 or not.  Unfortunately, we
> > > > > cannot blindly activate the "db_home: windows" setting because in some
> > > > > setups, the user's home directory is set to a hidden directory via an
> > > > > UNC path (\\share\some\hidden\folder$) -- something many programs
> > > > > cannot handle correctly.
> > > > 
> > > > -v, please.  Which applications can't handle that?  Why do we have to
> > > > care?
> > > 
> > > Oh, the first one that comes to mind is `cmd.exe`. You cannot start
> > > `cmd.exe` with a UNC working directory without getting complaints.
> > 
> > Sure, but then again, why do we have to care?  Didn't you say GfW is
> > using bash?
> 
> In particular, it affects all other native applications as well.  If that
> home setting works for the user outside GfW/Cygwin, and given Cygwin apps
> don't care, why should this suddenly be a problem for GfW?

I did say that Git for Windows uses bash to execute the shell scripts that
are part of Git. However, this says nothing about the *entry* point into
Git for Windows, which is quite often `cmd.exe`. Even worse: users are
free to provide hooks as batch scripts, in which case you encounter that
bad bug again.

The point you make about getent is a good one, I did indeed misunderstand
under what circumstances the modified code path is hit. I will change it
so that it only triggers for the current user.

Ciao,
Johannes