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: stdout not visible on some programs after upgrading from to 1.7.11-1 to 1.7.15-1


> -----Original Message-----
> Sent: Friday, June 22, 2012 19:11
> Subject: Re: stdout not visible on some programs after upgrading from to
> 1.7.11-1 to 1.7.15-1
> 
> >> I use cygwin on a windows 7 machine to automate a Visual Studio 10
> >> build from the command line. ?To do this, I invoke MSBuild.exe with a
> >> wrapper script called msbuild.sh (see below). ?Under cygwin 1.7.11-1,
> >> the stdout
> > from
> >> msbuild.exe appears on the console where I invoke msbuild.sh as
> expected.
> >> But after a recent upgrade to 1.7.15-1, the stdout stops appearing.
> >> By inspecting the running processes in the windows task manager, I
> >> see that msbuild.exe is launching the compiler, etc. ?Notably, if I
> >> replace the invocation of msbuild.exe with another program (e.g.,
> >> dir), I do see the expected stdout.
> >> Further, if I execute the relevant commands in the native cmd shell,
> >> I do
> > see
> >> the msbuild.exe output. ?I considered tracking down the specific
> >> package that lead to this regression, but I didn't find a mirror with
> >> the older
> > packages.
> >> Below I've pasted the output of cygcheck -c for the working and
> >> failing systems. ?Can somebody advise me on a sensible next steps to
> >> recovering the stdout of msbuild.exe?
> >>
> >> Please CC me in responses.
> >>
> >> Thanks,
> >> Brian
> >
> > <snip>
> >
> > Try both of the following:
> >
> > 1. ?Update to latest development snapshot, should resolve the bug you
> > are primarily observing.
> > 2. ?Set the CYGWIN environment variable to pipe_byte. ?Cygwin now uses
> > message pipes by default, which are not compatible with .NET Framework
> > and Visual C++ runtimes (not currently documented anywhere in Cygwin
> > or MS documentation).
> 
> For kicks, I tried 2 by itself.  This didn't change the behavior.
> Next, I tried 1 by itself as described in [1].  This worked.  Adding in
> CYGWIN=pipe_byte did not cause anything to change.  So I presume this will
> be fixed in the next release.  Thanks for your time.

That's because "pipe_byte" won't fix the problem of a hang.  What pipe_byte
will fix is allow all non-Cygwin programs to properly handle reading from
standard input.  That's because unmanaged VC++ and managed .NET runtimes
don?t support reading a message pipe standard input.  This compatibility
issue with these common Microsoft runtimes isn't yet in the Cygwin
documentation as far as I know, which is why I'm pointing it out to you -
since you're obviously using non-Cygwin programs.

Read the past discussions about this issue and you'll see why it's
necessary, if you want the technical details.  A message pipe might seem to
work 99% of the time, but then break.


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