fix might look like? Thank you for any feedback.
Best regards,
James Johnston
--
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
full control over the creation of the pipes and full control over the
reading/writing of the pipes - not the case here.
So I can see why they went for WaitForMultipleObjectsEx method... the other
methods have significant performance and/or functional limitations, and they
probably found out fr
r all I
know. I haven't yet had time to delve into what Cygwin does differently
from the other shells I tried. Maybe there is some uncommon pipe setting or
configuration that causes this issue...
Best regards,
James Johnston
--
Problem reports: http://cygwin.com/problems.html
FAQ
er hand, if removing the flag causes mass breakage, I am not sure what
the solution should be.
Best regards,
James Johnston
--
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
the FAQ as a requirement.
Best regards,
James Johnston
--
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
with standard error. I didn't test.
1. I assume this is a bug in Cygwin. Anything more I should do for
reporting it? (e.g. creating an issue/ticket)
2. Workaround suggestions?
3. Which part of Cygwin do I need to roll back to fix this issue for now?
Best regards,
James Johnston
-Or
I can reproduce this:
C:\cygwin\bin>perl -e 'print "abc";'
abc
C:\cygwin\bin>perl -e 'print "abc";' | more
abc
C:\cygwin\bin>perl -e 'print "abc";' | more
abc
C:\cygwin\bin>perl -e 'print "abc";' | more
C:\cygwin\bin>perl -e 'print "abc";' | more
C:\cygwin\bin>perl -e 'print "abc";' | more
I
I think this is a regression:
1. Used setup to install Cygwin package 1.7.10. Problem still exists.
2. Since setup did not offer me the ability to go back to 1.7.9, I found my
old archive for that version and extracted the bin files to manually go back
to that version. Problem fixed!
So it mu
You're partially correct, depending on how you look at it... As I wrote
earlier, I reproduced it with a straight Win32 program, too - by doing a
null write that every C# program would do. So I guess it's not specific to
C#, since C++ programs can cause it too. But every C# program would
normally
of the
C version is that it removes the rest of .NET from the test...
Best regards,
James Johnston
-Original Message-
Sent: Monday, March 12, 2012 14:19
Subject: Re: Can't reliably redirect standard output from C# program in recent
Cygwin
On Mar 12 14:05, James Johnston wrote:
&
I have also noticed this issue; again it was with the XML serialization
functions like Andres Martinelli originally noted. The root of the problem is
that Windows environment variables are not case sensitive, while they *are* in
a Unix environment. Cygwin passes an environment block with dupli
nd-of-file" function since it would have to be special-cased for
pipes (and who knows what else).
I wonder why it worked sometimes but not other times (e.g. running "echo
`./HelloCPP | cat`" would sometimes work, sometimes not)? With something
like this, I would think it would not work
I ran into similar issues, which seemed to be fixed in 1.7.12 - but if you
are still having issues even on the current Cygwin version of 1.7.13, I'd be
interested to know if they can be resolved. If it's anything like the issue
I found, it has to do with erroneous pipe handling in Cygwin and nothi
00 and 0x6000 on my main development
computer, which has a lot of stuff on it. And also several Windows XP
system DLLs (i.e. no ASLR) being placed in the 0x6000 range as well
(with an example being shown above).
Thoughts, anyone?
Best regards,
James Johnston
--
Problem reports: h
20, 2012 20:50
Subject: Re: Two probable basing issues causing fork failures: (1)
cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
ASLR-relocated/system DLLs
On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote:
>[snip]
>... Today this issue came
>
> -Original Message-
> Sent: Monday, April 23, 2012 14:51
> Subject: Re: Two probable basing issues causing fork failures: (1)
> cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
> ASLR-relocated/system DLLs
>
> Yes, it is a problem in the first place if DLLs have
> -Original Message-
> Sent: Tuesday, April 24, 2012 12:38
> Subject: Re: 1.7.10->1.7.13 : output from .NET programs does not get
through
> pipeline to a visual c++ program
>
> >>> begin readin.cxx
> #include
>
> int
> main(int argc, char* argv[])
> {
> static_cast(argc);
> stati
at the results are now correct.
The fact that Windows command prompt delivers correct results is probably a
reason why these bugs exist in the runtimes in the first place: probably
nobody really tested to make sure the runtime was compatible with other
redirected standard inputs that might have null w
> -Original Message-
> Sent: Friday, April 27, 2012 00:17
> Subject: Re: Cygwin passes through null writes to other software when
> redirecting standard input/output (i.e. piping)
>
> Nope, it won't always be that because I get what's expected. I built the
C++
> files using mingw g++. Al
> -Original Message-
> Sent: Friday, April 27, 2012 14:38
> Subject: Re: Cygwin passes through null writes to other software when
> redirecting standard input/output (i.e. piping)
>
> What I don't grok is this:
>
> In your example, A and B are both native (== non-Cygwin) applications.
>
> -Original Message-
> Sent: Saturday, April 28, 2012 23:03
> Subject: Putting package directory in c:\Cygwin
>
> Putting the packages directly in c:\Cygwin is ill-advised because it shows
up in
> the posix directory "/". It pollutes the directory with millions of
package
> folders. But
> -Original Message-
> Sent: Wednesday, May 09, 2012 19:00
> Subject: Re: Cygwin passes through null writes to other software when
> redirecting standard input/output (i.e. piping)
>
> I can't say with 100% certainty, but I would bet with 90+% confidence that
> this
> is a bug in MS's libra
> The cygwin DLL can't intercede here. It's not some superior process
> controlling I/O. It's just a DLL used by two programs. cat is writing to
the
> stdout that it inherited from the shell.
Good point, I had not thought this through enough. In this case, bash.exe
is asking CYGWIN1.DLL for a
In situations like this, it's useful to examine the .NET Framework and see
how the Microsoft implementation works. Generally, I find that the
implementations in the framework seem good and cover edge cases that I might
not normally think about.
In this case, the System.Console class has a method
> - Add CYGWIN=pipe_byte option to force opening of pipes in byte mode
> rather than message mode.
I can confirm that setting this fixes the test cases I was having problems
with. Thanks! :)
A suggestion: maybe modify the documentation to state why one would set this?
Current documentation
> On Tue, May 15, 2012 at 06:59:14PM +0200, Pawel Jasinski wrote:
> >i have discovered something peculiar.
> >I run my rxvt with the usual:
> >
> >C:\cygwin\bin\rxvt.exe -bg wheat -fg black -sl 5000 -e /bin/bash -ls
> >
> >now I try inside to run some *non* cygwin console program rxvt shows
> >noth
> 64-bit does not make things go any faster than 32-bit.
Not true for some applications. For one of our applications that uses very
large in-memory trees and is therefore heavy on the recursion, simply switching
the compiler to 64-bit provided a 10% performance boost. Other commonly used
comp
> How can 1000 machine instructions of 32 bit be larger than 1000 machine
> instructions twice that size! Unless vastly different code generation happens
> with 64 bit compilers the number of instructions emitted should be just
> about the same yet with 64 bit instructions are obviously twice as bi
> On 5/18/2012 4:37 PM, JonY wrote:
> >> OK, OK. Tack on "for most applications" to my statement (I thought it
> >> was assumed).
> > I believe the same was said when transitioning from 16bit to 32bit.
> If so then they were wrong.
Hey, why isn't "ls" a 16-bit program? Realistically, it does not
> -Original Message-
> Sent: Tuesday, May 22, 2012 06:14
> Subject: 1.7.15-1: mintty bash failing to run .NET executables ?
>
> After that, .NET programs failed to launch at all. The mintty bash
terminal just
> sits there, no CPU or anything else being used, the .NET .exe failing to
launch
> And only now I've found the messages talking about similar issues after
> fruitless Google searches. Same thing happens to me after I buy hardware.
>
> The problem appears fixed in the latest snapshot of cygwin1.dll.
Indeed it was; the problem happened for at least two other people on the
maili
> >Red Hat might not have to buy a code signing cert for this. They might
> >already have one that will work: http://goo.gl/5Hm3C
>
> The Cygwin project is not Red Hat. It wouldn't be "Red Hat" buying
anything.
What is the Cygwin project then? I honestly thought it was a Red Hat
project... I.
> -Original Message-
> Sent: Monday, June 18, 2012 16:34
> Subject: Re: sshd connections unexpectedly close on windows 2012
>
> > " 5 [main] sshd 180 fhandler_dev_zero::fixup_mmap_after_fork:
> requested 0xFEF2 != 0x0 mem alloc base 0x0, state 0x1, size
> 1179648, Win32 error
> -Original Message-
> Sent: Wednesday, June 20, 2012 16:27
> Subject: stdout not visible on some programs after upgrading from to
1.7.11-
> 1 to 1.7.15-1
>
> Hello,
>
> I use cygwin on a windows 7 machine to automate a Visual Studio 10 build
> from the command line. To do this, I invoke
> -Original Message-
> Sent: Thursday, June 21, 2012 15:55
> Subject: Re: Cygwin unstable as hell on Windows7 64bit
>
> On 21/06/2012 11:34 AM, Gerard H. Pille wrote:
> > I checked the BLODA, but with only the following programs left
> > running, Cygwin is still getting killed:
> >
> > $
> -Original Message-
> Sent: Friday, June 22, 2012 02:22
> Subject: cygwin 1.7.15-1 - .NET console output locks up mintty
>
> I have noticed a problem with the â"cygwin: The Unix emulation engine"
> package, version 1.7.15-1. Output from .NET console does not show up, the
> console
> (min
> -Original Message-
> Sent: Friday, June 22, 2012 18:11
> Subject: Re: cygwin 1.7.15-1 - .NET console output locks up mintty
>
> > > I have noticed a problem with the â"cygwin: The Unix emulation
> > > engine" package, version 1.7.15-1. Output from .NET console does
> > > not show up, th
> -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 MSBui
> -Original Message-
> Sent: Wednesday, July 11, 2012 19:34
> Subject: Re: running .bat file in cygwin
>
>
> "Note, fork requires the cygwin1.dll file. Are you prepared for that?"
>
> thanks for your response. What got me notice is the above comment?
> Would you please elaborate on tha
> -Original Message-
> Sent: Wednesday, July 11, 2012 20:07
> Subject: Re: CTRL+C is not working with java on latest cygwin 1.7.15
>
>
> Thanks for the reply "K Stahl", but it didn't work for me. I ran the same
Test,
> then press CTRL+C. But the cygwin terminal did nothing. It did not sto
> -Original Message-
> Sent: Friday, July 13, 2012 02:14
> Subject: Re: best way to re-install and keep cygwin configuration
>
> So I will just tar up the cygwin directory and put it back after the new
install. If
> I download a new copy of setup.exe and point it at the install directory,
> -Original Message-
> Sent: Friday, July 27, 2012 10:05
> Subject: RE: automatically using pipe_byte for certain EXE's
>
> Daniel Colascione wrote:
> >Since message pipes cause problems _in practice_ and byte pipes (which
> >Cygwin lived with for many years) don't seem to cause problems _
> -Original Message-
> Sent: Friday, August 10, 2012 04:13
> Subject: Re: running interactive process on xp through cron not working
>
> > Any ideas on how to make cron work to allow me run programs
> > interactively like notepad?
>
> To be honest, making this work is tenuous at best. MS
> -Original Message-
> Sent: Thursday, August 16, 2012 18:22
> To: Cygwin-L
> Subject: Re: Promote sqlite 3.7.13-1 from test status?
>
> On 8/16/2012 10:34 AM, Brian Wilson wrote:
> > is correct, Cygwin is supposed to be a Posix compliant environment
>
> It's also supposed to interoperate
> -Original Message-
> Sent: Tuesday, August 21, 2012 14:39
> Subject: Re: /etc/profile
>
>
> Eric Blake redhat.com> writes:
> > Unfortunately, at least your windows system dll directory has to be on
> > PATH, or cygwin1.dll will fail to load, so blindly removing ALL
> > windows paths fr
> -Original Message-
> Sent: Tuesday, August 28, 2012 07:09
> Cc: Aharon Robbins
> Subject: Re: stuff running slowly
>
> On 8/27/2012 11:28 PM, Aharon Robbins wrote:
> > Michael,
> >
> > Thanks for your note. I understand that process creation on Windows is
> > slower than on Linux. But wh
> -Original Message-
> Sent: Wednesday, September 26, 2012 11:57
> Subject: include SHA1/MD5 hash/digest of setup.exe, and HTTPS
>
> Hello,
> Please include SHA1/MD5 hash/digest code of "setup.exe" file, on webpage
> next to "setup.exe" download url-link.
> so we can know for sure, if we h
> -Original Message-
> Behalf Of Bry8 Star
> Sent: Thursday, September 27, 2012 05:14
> Subject: Re: include SHA1/MD5 hash/digest of setup.exe, and HTTPS
>
> James, you are right, a combination approach would be better.
>
> But before doing any major changes (on setup.exe), for now, at-le
48 matches
Mail list logo
