X-Spam-Check-By: sourceware.org
Message-ID: <4536FB0D.4080805@byu.net>
Date: Wed, 18 Oct 2006 22:11:57 -0600
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Re : [ANNOUNCEMENT] Updated [experimental]: bash-3.2-2
References: <Pine DOT OSF DOT 4 DOT 21 DOT 0610182140320 DOT 5779-100000 AT ax0rm1 DOT roma1 DOT infn DOT it>
In-Reply-To: <Pine.OSF.4.21.0610182140320.5779-100000@ax0rm1.roma1.infn.it>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Angelo Graziosi on 10/18/2006 1:42 PM:
> I have tried to install this but the installation hangs running
> /etc/postinstall/00bash.sh.

Hmm, I saw that too, but cancelling setup.exe and manually running the
script from cmd.com worked.  I'm not sure what the interaction is that
seems to be causing that.  In looking further, I'm seeing a process tree
that looks like:

?-+-bash---bash---uname
  `-pstree

I'm not sure how uname is entering the picture; 00bash.sh doesn't directly
call uname.  My guess is that somehow the new /bin/bash is thinking that
it should be interactive when invoked by setup.exe, and thus running
uname, then hanging when uname doesn't respond correctly.  I'm baffled as
to what is causing this behavior.  After using /bin/kill -f on that uname,
I then get to the cygpath and sed processes run by the first command
substitution in 00bash.sh; those processes also seemed to hang.

On the other hand, I did intentionally skip out on porting one of the
cygwin-specific patches that was in subst.c in 3.1, related to creating
pipes between processes.  The comment along with that patch was:

+#if __CYGWIN__
+  /* Ensure that stdin, stdout, and stderr have a valid file descriptor, so
+     that pipe doesn't end up in those slots; otherwise a hang might
+     result when leaving one end of the pipe open in the subprocess. */
+  int i, closeit[3];
+#endif /* __CYGWIN__ */

I had hoped that cygwin had advanced beyond that point (as it was, CVS
cygwin has a fix in newlib's pipe() call that overcomes a bug in cygwin
1.5.21 and earlier when stdout is closed), but based on the behavior we
both saw, it looks like I will have to port that patch to bash 3.2 after
all, to see if it improves the situation.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNvsN84KuGfSFAYARAqawAJ4rWHpz/olmOTH30zkP5mKhqaePUgCfTDeI
VbrD98PUMoOhiBb7SenfrnA=
=5AxP
-----END PGP SIGNATURE-----

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