X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=amq4RD6blD0T4oix
	VQ3wFXC12R8v4Xaea/vFOWxIXSfhEonG/1aTc+X+2JXFam7fk2p25Aa+Q2Y34goe
	f7E57+YGQ53PsbiDfRTlyRqjclfGrhQBRubReYcdDvDC71fjq0s8QqKReN2z2PXy
	mzJhZeybYACwqW5JBIwuRAF6gzk=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=n6puoGj7SPz5Kl5Dl03/E2
	Ssf1E=; b=h3RksxP2jGb1Hxeg2dPgVbsvl1lp3lZQ6jaN+KSZ89/xHreMuS3FLu
	R3NMpfOcaeBdqTmoX56tKidCPTyhks7Zlh6C1J+k1HxROaYTKZdORYUOPJFs+ICl
	b5x6abXHS5ibckyzu1BS9X1VF6zunO3pNMvNz30AX5wq2EeXWnj/g=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_BODY_URIBL_PCCC,KAM_FROM_URIBL_PCCC,KAM_THEBAT,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO:	smtp.ht-systems.ru
Date:	Sun, 15 Feb 2015 21:36:16 +0300
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<131240804.20150215213616@yandex.ru>
To:	Corinna Vinschen <cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.1
In-Reply-To:	<20150215100515.GK7225@calimero.vinschen.de>
References:	<announce DOT 20150212202323 DOT GI7818 AT calimero DOT vinschen DOT de> <74410B36-A057-483B-AAA3-20C15934374E AT Denis-Excoffier DOT org> <2F8A6D52-E4D9-48D0-BC21-13213AAC9F4B AT etr-usa DOT com> <A2F3E911-AA9A-4CFD-ACA7-9C5269339F92 AT Denis-Excoffier DOT org> <646732991 DOT 20150214022454 AT yandex DOT ru> <54DF0337 DOT 7090405 AT towo DOT net> <767189166 DOT 20150214222127 AT yandex DOT ru> <20150215100515 DOT GK7225 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
X-IsSubscribed:	yes

Greetings, Corinna Vinschen!

>> >> I have a feeling that you have %HOME% defined before mintty starts.
>> >> I just made some tests, and it seems to be the showstopper.
>> >> If %HOME% is already set, nsswitch.conf:db_home is ineffective.
>> >> Simple check for
>> >>
>> >>      SET HOME=
>> >>      mintty -
>> > I think setting HOME globally, before starting cygwin, is the most 
>> > straightforward way to configure one's home directory preference and 
>> > should thus be supported.
>> 
>> Supported, allright.
>> The issue seems to be contradiction between documented and observed behavior
>> of a specific macro. (Or specific part of the Cygwin, to that extent.)
>> Setting global %HOME% to %HOMEDRIVE%%HOMEPATH% is a natural choice, but Denis
>> seems to want a deviation of it for Cygwin specifically.

> Apples/oranges.  I'm talking about the passwd entry and creating
> passwd entry requires some kind of reproducability.
> The environment of the current user has nothing to do with it.
> I hope https://cygwin.com/ml/cygwin/2015-02/msg00425.html makes that clear.

I apologize for not being thorough in my initial testing.
As you can see below, I've found that Cygwin behave exactly as described.
And in regard to bash, it also behave as intended. Or at least, the observed
behavior on Linux host I can check with is same as one observed under Cygwin.
`sudo -E -u otheruser bash -l` start using currently defined $HOME.

>> By the way,
>> getent passwd %USERNAME%
>> return homedir correctly, but bash insist on using existing HOME even if
>> started as login shell.

> Of course.  All shells do that.  They expect HOME to have a useful value
> because HOME is usually set by the login process before the shell is
> started.  And the login process, if there is any, fetches HOME from the
> account DB.

That makes me wonder, if there's a sane way to simulate such login process
under cygwin without asking user for name/password?
Or unsetting global %HOME% is the only way to go?


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 15.02.2015, <21:27>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -