This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 'cmd /C start cmd' no longer non-blocking (base-cygwin 3.1-1), but used to work (in base-cygwin 3.0-1)

On Fri, May 04, 2012 at 04:41:12PM +0000, Petrisor Eddy-Marian-B36037 wrote:
>> On 5/4/2012 3:43 PM, Petrisor Eddy-Marian-B36037 wrote:
>> > Hello,
>> >
>> > I am using at work cygwin on various machines (XP and Windows 7) and
>> made several scripts that use gnu utilities from cygwin. One of those is
>> a script that starts in paralel instances of cmd various parts of a build
>> system through a sh script that invokes 'cmd /C start ...' to start those
>> parts of the build system in a non-blocking fashion.
>> >
>> > Recently, on one of the machines which had its cygwin installation
>> upgraded, I have observed that the cmd instances do not start in a non-
>> blocking fashion anymore, but instead wait for the process to finish.
>> >
>> >
>> > To be more precise, following the following steps should lead to two
>> interactive windows, one with the sh prompt and one with the cmd prompt,
>> both waiting for user input:
>> > 1 - start a cygwin (or sh) command window
>> > 2 - type "cmd /C start cmd"
>> try
>> cmd /C start cmd &
>[Petrisor Eddy] 
>I know about how to work around the issue, but the problem is that
>cygwin somehow interacts with start and renders it useless.  If 'cmd /C
>some_command' has the same effect as 'cmd /C start some_command' under
>sh/cygwin, while working as expected in pure cmd, then cygwin is
>behaving badly and this issue is the one to be addressed especially
>since it is a regression.

How about if I make it official: The change in behavior is due to some
changes in 1.7.1* which were required to improve stability with execed

So, please use the workaround.  We make no guarantees about how the
start command in CMD will interoperate with Cygwin but we do guarantee
that "&" will always create a background process.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]