Hi,
Thank you for your reply.
On Thu, Feb 20, 2020 at 8:01 PM Takashi Yano
wrote:
> Thanks for the test case. Indeed, this works upto cygwin 3.0.7,
> and does not work in cygwin 3.1.0 or later.
>
> However, I wonder what platform is your program for. This test
> case does not work also in nativ
Hi Takashi,
On Tue, Feb 18, 2020 at 2:43 PM Takashi Yano wrote:
> Could you please provide a simple test case?
Here you go:
// pipes.cpp
//
// Compile in a Visual Studio x64 Native Tools Command Prompt:
// cl pipes.cpp /link /subsystem:windows
//
// Run from inside a Cygwin shell, the pro
anymore.
Any ideas?
-Edward
On Fri, Jan 31, 2020 at 1:25 AM Edward Lam
wrote:
> On Thu, Jan 30, 2020 at 5:25 PM Takashi Yano
> wrote:
>
>> Probably, this is the same issue as
>> https://www.cygwin.com/ml/cygwin/2020-01/msg00093.html.
>>
>> Please try lat
On Thu, Jan 30, 2020 at 5:25 PM Takashi Yano
wrote:
> Probably, this is the same issue as
> https://www.cygwin.com/ml/cygwin/2020-01/msg00093.html.
>
> Please try latest cygwin snapshot.
> https://cygwin.com/snapshots/
>
>
Indeed, this works again after 20202401 snapshot!
Thanks,
-Edward
--
Pr
Hi Folks,
I'm getting a problem where cygwin parent processes spawning non-cygwin
child processes no longer detect when stdin has been closed. Please see the
sample python code at the end where I've isolated the problem. I've got
cygwin's python2 running spawn_bar.py that popen's a native non-cygw
Hi Folks,
I finally got down to looking at how to fix this in dash and came up
with the attached patch (against dash-0.5.7). It's simple enough and so
cd now works.
Please consider this for Cygwin.
Thanks!
-Edward
On 03/12/2011 5:11 PM, Eric Blake wrote:
On 03/05/2010 10:20 AM, Corinna Vi
It should probably noted on the website that building Cygwin requires
the gcc4 package. For example, here:
http://cygwin.com/faq.html#faq.programming.building-cygwin
-Edward
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentatio
On 31/05/2011 10:54 AM, Christopher Faylor wrote:
Oh, and, btw: All clear!
So cygwin1-20110531.dll.bz2 is good?
-Edward
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On 29/04/2011 2:35 PM, John Dong wrote:
Reproducing this seems nondeterministic -- sometimes I can get it to
happen in 5 minutes, other times it takes overnight. I've tried using
a different shell (like dash), but it doesn't make a difference,
leading me to suspect this to be a lower-level issue
On 5/11/2011 11:02 AM, Edward Lam wrote:
So this brings us to Cygwin. When we spawn such a Windows mode app from
Cygwin, the method I describe above fails. The call to
_open_osfhandle(info.hStdOutput, _O_TEXT) returns with an error value of
-1. This is likely why jam reports "the hand
On 5/11/2011 2:34 AM, Corinna Vinschen wrote:
Kind of weird. The difference is that in tty mode the stdio handles are
pipes, while in the notty case the stdio handles are console handles.
Usually native Windows applications shouldn't see a difference and even
work *better* in notty mode.
One p
On 5/9/2011 12:10 PM, Corinna Vinschen wrote:
Chris and I are wondering how many people are using the Windows console
as local console window in CYGWIN=tty mode and why.
I'm not but there's various references to it it the web about it being
requires for Emacs. eg.
http://blog.arithm.com/2007/
On Wed, April 20, 2011 21:06, Christopher Faylor wrote:
> But, for now, just setting the base to something higher:
>
> rebaseall -b 0x7700
>
> would solve some of the problems we've seen.
>
> I don't know if that stomps on system routines or not, though.
Just curious, why is this even a proble
On 3/31/2011 4:34 PM, Corinna Vinschen wrote:
Is anybody here still using Cygwin on Windows NT4 on a daily basis? I'm
asking because we're planning to drop NT4 support entirely and I would
like to know if there are lots of people who would be very sad if that
happens.
No, but I'm curious as to
On 3/2/2011 9:05 AM, Jim P wrote:
I just updated my cygwin install, and cygpath appears to be broken. Issuing the
command "cygpath", with any or no command-line options, returns nothing and a
status of 127.
But other commands work? eg. ls ... If you've rebased your cygwin
install in the past,
Dear Cygwin gurus,
I'm hoping to find some solution to the problem where if a file is
modified by a native Windows application, it becomes "executable"
according to cygwin.
After some searching, it appears that the only way to do this is by
setting the noacl mount option by appropriately man
On 10/19/2010 3:30 PM, Gerrit P. Haase wrote:
I don't get it. What is the problem? What can I do? Where to look
first? How to fix this disagreeableness?
This is probably the same problem as tracked down previously:
http://cygwin.com/ml/cygwin/2010-08/msg00964.html
This is the last I hea
testing on /tmp/benchmark with XPS P2
cygwin 1.7.8s 20100924
You're testing on the latest snapshot against his cygwin 1.7.7 results.
This gives me hope that Cygwin can become faster because Sagi Ben-Akiva
was willing to track down the cause of the slowdown [1]. Last I read,
it's not clear wh
On 9/1/2010 1:12 PM, Magnus Holmgren wrote:
To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure
it was always called in dll_crt0_1 instead. Suddenly the sigp thread started
executing immediately, and its initialization was complete long before
wait_for_sigthread was call
On 8/31/2010 10:08 AM, Christopher Faylor wrote:
Here's what I'm saying: It makes absolutely no sense that moving the
call would have any effect. The code is the way it is for a reason
so we're not going to just revert the change.
I don't think anyone is asking to revert the change.
In any
On 8/30/2010 7:16 AM, Sagi Ben-Akiva wrote:
2. a. Moving the call to wait_for_sigthread from dll_crt0_1 to _dll_crt0
which calls dll_crt0_1.
b. Deleting the call to WaitForSingleObject,
i.e. : "Don't worry about sync_startup"
I can confirm that the 2nd sub-change is the cause for the slowdown.
On 8/30/2010 10:45 AM, Corinna Vinschen wrote:
What am I missing?
cygthread::operator new(size_t)
Thanks!
-Edward
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Hi,
In looking at slowdown problem on x64 systems by Sagi Ben-Akiva, I found
some puzzling code that perhaps someone could enlighten me on. I must be
reading it wrong.
Here's the code path that I'm tracing using cygwin-src-20100829.tar.bz2:
- In dcrt0.cc, if dynamically_loaded is true, then
On 8/30/2010 7:16 AM, Sagi Ben-Akiva wrote:
For the last couple of weeks I'm trying to identify the cause for
cygwin slowdown on x64 machines which was reported by David Morgan
about 6 months ago.
You're my new hero. :)
I then applied the changes one by one and built cygwin1.dll for each
chan
Hi Jason,
Jason Tishler wrote:
On Tue, Jun 22, 2010 at 09:59:30AM -0400, Edward Lam wrote:
I just updated my cygwin installation and it looks like my old
python2.5 installation has been corrupted?
When you updated your Cygwin installation, you updated Python to
python-2.6.5-2:
So is the
Hi,
I just updated my cygwin installation and it looks like my old python2.5
installation has been corrupted? /usr/python2.6 has all the usual
packages but /usr/lib/python2.5 is missing everything. I have attached
my latest cygcheck -s -v -r output and the corresponding setup.log.full
from my
NightStrike wrote:
Port cygwin to win64 via mingw-w64 :) :)
I'm not convinced that this will help. As mentioned already, there was a
very specific change between cygwin releases that resulted in the slow
down. It would be more helpful if someone actually compared the source,
ran some profile
Corinna Vinschen wrote:
On Mar 5 10:10, Eric Blake wrote:
Let's rule out bash vs. dash complexities, and first focus on whether
cygwin1.dll might be at fault. Untested code:
#include
#include
#include
#include
int main(int argc, char**argv)
{
int e = chdir(argv[1]);
char *cwd = getcwd
Corinna Vinschen wrote:
Is that a case-sensitivity issue, perhaps? See
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
And in case you missed this the first time, it works fine in bash
$ bash
$ cd c:/
$ pwd
/c
$ export FOO=c:/windows
$ cd $FOO
$ pwd
/c/windows
Edward Lam wrote:
Edward Lam wrote:
Corinna Vinschen wrote:
Is that a case-sensitivity issue, perhaps? See
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
I don't see how it is:
$ dash
$ cd /c
$ ls -d W*
WINDOWS
$ cd c:/WINDOWS
cd: 3: can'
Edward Lam wrote:
Corinna Vinschen wrote:
Is that a case-sensitivity issue, perhaps? See
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
I don't see how it is:
$ dash
$ cd /c
$ ls -d W*
WINDOWS
$ cd c:/WINDOWS
cd: 3: can't cd to c:/WINDOWS
$ cd
Corinna Vinschen wrote:
Is that a case-sensitivity issue, perhaps? See
http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive
I don't see how it is:
$ dash
$ cd /c
$ ls -d W*
WINDOWS
$ cd c:/WINDOWS
cd: 3: can't cd to c:/WINDOWS
$ cd C:/WINDOWS
cd: 4: can't cd to C:/W
Eric Blake wrote:
According to Edward Lam on 1/21/2010 7:12 AM:
DOS file paths and dash seems to NOT support them
Huh? Give an example. dash supports DOS paths the same as bash. That
is, if the : doesn't already cause other problems (as in tar), then the
DOS path is handed on to n
Eric Blake wrote:
The package dash has been upgraded to 0.5.5.1-2 for those using cygwin
1.7, simultaneously replacing dash-0.5.5.1-1 and ash-20040127-4. The ash
package is now obsolete; ash.exe is provided by the dash package.
I know I'm slow but I just updated to this cygwin change and runni
On Tue, December 29, 2009 19:09, Rob Walker wrote:
>
> Here are links to the patches I've applied to construct this package:
>
> http://lists.gnu.org/archive/html/make-w32/2006-09/msg00037.html
> http://lists.gnu.org/archive/html/make-w32/2007-12/msg00015.html
>
Ah, ok, the patches are
Hi Rob,
Rob Walker wrote:
It's been almost a year and a half since I made a request to have
Cygwin's GNU make updated with the upstream patches for colons in
dependencies and VPATH directives:
Is this patch submitted upstream to the gmake project? I imagine it
would be helpful to the HAVE_DO
Larry Hall (Cygwin) wrote:
- In my experience, I have to rebase everything (Windows 7, like
Vista, shows this fork-failure behavior depending on where dll's
load into virtual memory); that's ok, though not fun
I haven't found that on any of my Win7 installations but that probably
reflects more
Does anyone know of the status for Unicode filename support in the cygwin
1.7 version of Python? The last mail I found was:
Corinna Vinschen wrote:
"Uh, so python needs a rebuild for Cygwin to deal with localized
pathnames correctly. I assume it's missing to call the conversion
functions because
Corinna Vinschen wrote:
I think dash is preferred in future. In theory we should dash hardlink
to ash and deprecate the ash package entirely. It's about time. Eric?
Is dash as fast as ash?
-Edward
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwi
Eric Blake wrote:
So for now, there are no plans of replacing /bin/sh with dash.
Incidentally, I copy ash.exe over to sh.exe every time for performance.
AFAICT, /bin/sh defaulted to bash (from ash) back in the bash 3.0 series
to be more "similar to Linux distributions". It took me quite some
On Sun, July 5, 2009 13:49, Jerry DeLisle wrote:
> Fresh install still broken with backing down one rev on bash and using
> libreadline6.
I ran into this Friday as others have noted. The thing that caught me was
that the postinstall scripts in the installer rely on a working bash. Once
I had a bro
Eric Blake wrote:
61020293 looks like an address in the dll range, probably cygwin1.dll. It
would be nice to know what function is dying, but doing that may require
rebuilding a bash image with debugging symbols. Did you by chance do any
rebasing? Maybe this is a case where I didn't use the co
upted stack)
I've attached the bash.exe.stackdump.
-Edward
Edward Lam wrote:
Hi Eric,
I seem to no longer be able to install bash 3.2.49-22 in cygwin 1.7? I
even tried doing a fresh cygwin install, choosing explicitly to use bash
3.2.49-22 instead of 3.2.49-23. During the installation, I g
Hi Eric,
I seem to no longer be able to install bash 3.2.49-22 in cygwin 1.7? I
even tried doing a fresh cygwin install, choosing explicitly to use bash
3.2.49-22 instead of 3.2.49-23. During the installation, I get an error
saying that cygreadline6.dll is missing. Any ideas?
I also tried do
Christopher Faylor wrote:
On Thu, Jul 02, 2009 at 08:51:47AM -0400, Edward Lam wrote:
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
"Why is Cygwin so slow" threads that have been here in the last
month. Every special case accomm
Christopher Faylor wrote:
And for those who want to wail about this, take a look at the various
"Why is Cygwin so slow" threads that have been here in the last
month. Every special case accommodation we make to allow MS-DOSisms
to work seamlessly adds code to Cygwin and cause corresponding s
On Wed, July 1, 2009 22:17, Eric Blake wrote:
> It also removes special
> handling for DOS paths, since cygwin 1.7 is less accommodating to those
> (use /cygdrive instead).
Can you clarify what this means exactly compared to say the latest bash
version in cigwin 1.5? Personally, I rely on using DO
On Wed, June 24, 2009 21:53, Edward Lam wrote:
> PS. So I went ahead and repeated the tr test on an older (Intel Core 2
> Quad 2.66 GHz) machine with cygwin 1.5 on Windows *32-bit*:
Sorry, I got the system specs wrong. It's actually just an Intel Core 2
6600 2.40 GHz machine.
>
&
rocessor ONE GENERATION
OLDER, on an older version of cygwin, yet being a few times FASTER.
On Wed, June 24, 2009 21:49, Edward Lam wrote:
> On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote:
>> Sure, we all know that Cygwin provides Linux emulation and suffers some
>> overhe
On Wed, June 24, 2009 17:29, Larry Hall (Cygwin) wrote:
> Sure, we all know that Cygwin provides Linux emulation and suffers some
> overhead for it. But timings from an individual machine can be
> misleading.
> Running this through multiple times for both Mingw and Cygwin 1.7 on my
> similarly equ
Larry Hall (Cygwin) wrote:
> Interesting. I'm not sure why using Cygwin's 'make' would slow things
> down dramatically when running from a Cygwin terminal or shell. I can
Note that cygwin's make is just plain slower that mingw's make to begin
with. I'm not quite sure I can explain the ~25 time
Hi,
Whenever I do a "mount -c /" in cygwin 1.7, it seems to revert back to
/cygdrive after rebooting on Windows XP x64. Any ideas on how to have
the mount point change persist through reboots?
Thanks,
-Edward
--
Problem reports: http://cygwin.com/problems.html
FAQ: ht
Christopher Faylor wrote:
On Mon, Jun 22, 2009 at 03:10:19PM -0400, Edward Lam wrote:
Dave Korn wrote:
Larry Hall (Cygwin) wrote:
2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as
needed. This can get tricky/cumbersome in some cases.
It can be a lot
Dave Korn wrote:
Larry Hall (Cygwin) wrote:
2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as
needed. This can get tricky/cumbersome in some cases.
It can be a lot easier if you have a Makefile-based build system, where you
can do the conversion on things that yo
On Mon, June 15, 2009 19:53, Sisyphus wrote:
> Here are some timings I did recently for building the mpc-0.6 library.
> On Vista and XP, (in the same version of the MSYS shell, and using the
> same
> version of MinGW's gcc) I ran:
>
> ./configure --disable-shared --enable-static CPPFLAGS=-I/usr/loc
Christopher Faylor wrote:
As Corinna said above: "Chris implemented using the invalid code point
solution"
That's what is in Cygwin's CVS and in the latest snapshot.
I see, you silently committed a fix while this discussion was ongoing?
http://www.cygwin.com/snapshots/winsup-changelog-2009053
IWAMURO Motonori wrote:
And, I think that UTF-8 is best solution when the setting of LC_CTYPE
category is C.
2009/6/4 IWAMURO Motonori :
I think that this problem is caused by missing setting the locale
environment variable.
Therefore, I think that the problem can be solved by compelling the
se
Corinna Vinschen wrote:
On Jun 3 12:02, Christopher Faylor wrote:
On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote:
On Jun 3 09:18, Edward Lam wrote:
Corinna Vinschen wrote:
The question is, what do you expect? [...]
[...]
Wikipedia has several suggestions on how to
Corinna Vinschen wrote:
No. I'm suggesting to convert the command line always using the default
ANSI codepage, same as Windows when calling CreateProcessA. This only
affects non-Cygwin processes anyway since Cygwin uses another mechanism
to send the command line arguments to the child process.
Corinna Vinschen wrote:
What's left as questionable is the LANG=C default case. Due to the
discussion from the last month we now use UTF-8 as default encoding,
because it's the only encoding which covers all (valid) characters.
Sure, we could also convert the command line using the current ANSI
Corinna Vinschen wrote:
On May 29 17:21, Edward Lam wrote:
I think the problem I'm running into is: - I give cygwin 1.7's bash
a string that is in my system default code page. - cygwin 1.7
thinks the string is actually UTF-8 and tries to convert it as
UTF-8 into UTF-16, resu
>> Ok, so where's the bug tracker so I can log a bug?
>
> Isn't this mailing list serving as bug tracker? I just hope that
> whoever can fix this is reading our emails and will come up with the
> right solution.
Given the lack of developer acknowledgment (or refutation), I'm not
getting my hopes u
Repost for mailing list.
On Sat, May 30, 2009 at 6:03 PM, Edward Lam wrote:
>> Here, when I use russian Windows and I don't have LANG set (or when I
>> have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So
>> both, russian and european/chinese/japanese
I'm reposting since I didn't mean to send this privately.
On Fri, May 29, 2009 17:22, Alexey Borzenkov wrote:
> Here, when I use russian Windows and I don't have LANG set (or when I
> have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So
> both, russian and european/chinese/japanese
mmandLineW() directly seems to give a truncated command line
as well.
Regards,
-Edward
Alexey Borzenkov wrote:
On Sat, May 30, 2009 at 12:10 AM, Edward Lam wrote:
Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision
to use UTF-8 for the C locale is questionable.
No
Unicode, non-CodePage
aware native applications will be broken for you too with the current
default cygwin 1.7 behaviour.
Or is this, not a case that you care about and you *only* use cygwin
applications?
Regards,
-Edward
Alexey Borzenkov wrote:
On Sat, May 30, 2009 at 12:10 AM, Edward Lam
29, 2009 at 8:22 PM, Edward Lam wrote:
I think there is still a bug here? I set LANG=C, then shouldn't be just NOT
doing any encoding, thus work? If I do this on Linux, it works. If I use a
cygwin compiled app, it also works.
On Linux, internally, system uses multibyte strings (it is encodin
t
NOT doing any encoding, thus work? If I do this on Linux, it works. If I
use a cygwin compiled app, it also works.
-Edward
2009/5/30 Edward Lam :
IWAMURO Motonori wrote:
The encoding of C locale is ASCII, and not ISO-8859-1.
I don't think ASCII is the same as ISO-8859-1.
Does it work
omitted...)
$ ./bug arg1 "before `cat copyright.txt` after" arg3
0: E:\cygwin1.7\tmp\bug.exe
1: arg1
2: before
Regards,
-Edward
2009/5/29 Edward Lam :
Alexey Borzenkov wrote:
On Thu, May 28, 2009 at 7:28 PM, Edward Lam wrote:
PS. In case you haven't noticed, copyright.txt is not a
Alexey Borzenkov wrote:
On Thu, May 28, 2009 at 7:28 PM, Edward Lam wrote:
PS. In case you haven't noticed, copyright.txt is not a long file. It
consists of a single byte, 0xA9.
Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8
and the encoder fails.
How i
PS. In case you haven't noticed, copyright.txt is not a long file. It
consists of a single byte, 0xA9.
Edward Lam wrote:
Hi Larry,
> This sounds allot like this report to me:
>
> <http://cygwin.com/ml/cygwin/2009-05/msg00611.html>
I don't think it's the
Hi Larry,
> This sounds allot like this report to me:
>
> <http://cygwin.com/ml/cygwin/2009-05/msg00611.html>
I don't think it's the same bug because if I replace copyright.txt with
a single printable character (eg. c), then it works.
Regards,
-Edward
Larry Hall (C
Hi Cygwin 1.7 developers,
I think I've encountered bug in cygwin 1.7.0-48 on WinXP 32-bit. It
seems that passing a character on the command line (from either ash.exe
or bash.exe) that is greater than 127 to a native win32 process results
in arguments being truncated.
Hopefully you can reprod
Hi,
Has anyone ported cygwin to the IA64 yet?
Thanks,
-Edward
(Please cc my e-mail as I won't be able to regular check messages here)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.co
74 matches
Mail list logo
