DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; q=dns; s=default; b=bUJ
	MXxGUObcu7Wszc7jF1HCYwMnWSBJzbsY0znkiIDOVeIQgTC9E+SqTebCSYFyw4ng
	w8/l2AVG2KanbHE2DSUa5Te5XPvkh5X84bobjn01J48OgqShsUFAiaAux0aEF+wR
	RBPduQ3eVue9ElV/Ed4LxwO46mQZlP+PxQ3Vujfw=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <521571A7.6010503@gmail.com>
Date: Thu, 22 Aug 2013 11:04:23 +0900
From: nu774 <honeycomb77@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: shell-init: error retrieving current directory
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi, I've experienced the same issue. From what I can see:
Current bash.exe of cygwin64 seems to be improperly built with
HAVE_GETCWD disabled, which result in using it's own getcwd
implementation in the bash source package.

This can be indirectly observed by inspecting bash.exe with dependency
walker or something. You can easily see that bash.exe has it's own
getcwd symbol, and it's not imported from cygwin1.dll.

Therefore, I downloaded bash source package from setup-x86_64.exe anyway
to see what's happening, and built bash with cygport.
Surprisingly, I got working bash.exe with HAVE_GETCWD enabled, without
patching anything.
This one, of course, imports getcwd from cygwin1.dll, and is free from
the issue.

So I don't know why the HAVE_GETCWD was disabled on the official build,
but I think simple re-building and re-distributing of bash.exe will
solve this issue.


--
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