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

> 
> >
> > Expected result:
> > Two interactive and usable windows, one with the sh prompt, one with
> the cmd prompt, both waiting for user input.
> >
> > Actual result:
> > Two windows, one with sh and one with cmd, Cygwin/sh window blocked and
> waiting for the cmd window to finish.
> >
> >
> >
> > On another machine that hasn't had its cygwin install upgraded, the
> behaviour is the expected one. Here are the versions of the relevant
> packages that are found by the setup.exe to be upgradable on the working
> machine and the versions of the same packages on the non-working machine:
> >
> > Working machine package versions:
> > base-cygwin 3.0-1
> > csih 0.9.5-1
> > cygutils 1.4.8-1
> > cygwin 1.7.11-1
> > rebase 4.0.1-1
> >
> > Non-working machine package versions:
> > base-cygwin 3.1-1
> > csih 0.9.6-1
> > cygutils 1.4.10-2
> > cygwin 1.7.14-2
> > rebase 4.1.0-1
> >
> > Note: There are other packages which could be upgraded on the working
> machine, but they are irrelevant: diffutils, file, gawk, groff sed and
> tzcode.
> >
> >
> > Any help would be appreciated.
> >
> > P.S.: Please CC me, I am not subscribed.
> >
> > Eddy
> >
> 



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


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