This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.7.13/1.7.14: Issue with command prompt not returning when forking process
On May 5 10:05, Rob Burgers wrote:
> The issue I'm raising in here may be related to this post: http://cygwin.com/ml/cygwin/2012-05/msg00081.html
> It is the first time I read that something may have changed in this area. This is to me unexpected and it caused us quite some debugging to find out as the relation between the updated kernel release due to installation of new packages and the appearance of the issue were not so obvious.
> The example I'm providing in this post is a much simplified version of the actual application. In our application the Launcher (L) process is called from a script and the exit code of the process is needed to determine the next step. Since L never returns until the forked process (S) terminates the exit code will not be available. So running L as a background process doesn't help here.
> I also noticed the difference in behaviour between Cygwin and Linux and since it is Cygwin's intention to provide a Linux look and feel on a Windows environment, I wondering if it is meant to be like this. More over: In the 1.7.10 release the behaviour was still identical to Linux.
> If the statement in the other post remains, I'm wondering whether it would be possible to make the old-behaviour available e.g. by means of a registry key?
If Cygwin behaves different than Linux then that's not really intended.
However, this only goes as far as Cygwin processes are affected. We
can't (and don't) make any such guarantee for native, non-Cygwin
Are the affected processes Cygwin processes? If so, can you please
provide a very simple testcase in plain C?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple