Re: [PATCH] fix broken mouse in Cygwin 1.7.14 and 1.7.15

[Christopher Faylor]

On Thu, May 17, 2012 at 01:20:06AM +0200, Mikulas Patocka wrote:
>On Thu, 17 May 2012, Mikulas Patocka wrote:
>
>> > Corinna Vinschen:
>> >
>> > > 2012-04-03  Thomas Wolff
>> > > 
>> > >  * fhandler.h (class dev_console): Two flags for extended mouse modes.
>> > >  * fhandler_console.cc (fhandler_console::read): Implemented 
>> > >  extended mouse modes 1015 (urxvt, mintty, xterm) and 1006 (xterm).
>> > >  Not implemented extended mouse mode 1005 (xterm, mintty).
>> > >  Supporting mouse coordinates greater than 222 (each axis).
>> > >  Also: two { wrap formatting consistency fixes.
>> > >  (fhandler_console::char_command) Initialization of enhanced 
>> > >  mouse reporting modes.
>> > 
>> > 
>> > Patch applied with changes.  Please use __small_sprintf rather than
>> > sprintf.  I also changed the CHangeLog entry slightly.  Keep it short
>> > and in present tense.
>> 
>> Hi
>> 
>> The change (sprintf -> __small_sprintf) that Corinna applied actually 
>> broke mouse reporting. It is broken in Cygwin 1.7.14 and 1.7.15.
>> 
>> When the user clicks with the first button, the mouse down event is 
>> reported incorrectly, the mouse down event always looks like this:
>>  1b 5b([) 4d(M) 30(0) 78(x) 32(2)
>> Note that there is 0x30 (instead of 0x20) as the button. And there are 
>> always fixed coordinates (0x78, 0x32), regardless of where the user 
>> clicks.
>> 
>> This bug breaks the Links textmode browser (if you click on the top line, 
>> you should see the menu, but you don't with Cygwin 1.7.14 and 1.7.15). It 
>> also break Midnight Commander (if you start it with "TERM=xterm mc") and 
>> all other programs that use xterm-style mouse reporting.
>> 
>> The reason is that __small_sprintf and sprintf aren't equivalent. 
>> __small_sprintf processes '%c' format string differently from sprintf. A 
>> piece of code from smallprint.cc:
>> 
>> case 'c':
>>   {
>> int c = va_arg (ap, int);
>> if (c > ' ' && c <= 127)
>>   *dst++ = c;
>> else
>>   {
>> *dst++ = '0';
>> *dst++ = 'x';
>> dst = __rn (dst, 16, 0, c, len, pad, LMASK);
>>   }
>>   }
>>   break;
>> 
>> We see that if the character is outside the range 0x21..0x7f, 
>> __small_sprintf prints 0x and the hex value. On the other hand, sprintf 
>> copies the byte unchanged.
>> 
>> __small_sprintf("%c", 32) doesn't print space, it prints 0x20 --- and this 
>> breaks mouse click reporting. It also breaks the extended coordinate 
>> reporting implemented by Thomas because it need to print characters >= 
>> 0x80.
>> 
>> The attached patch fixes the mouse bug by changing __small_sprintf back to 
>> sprintf. Alternatively, you can fix __small_sprintf to process "%c" 
>> consistently with sprintf, but I don't know how much other code is 
>> dependent on the current peculiar "%c" processing. So it's safer to change 
>> mouse reporting calls to use sprintf.

I don't know where that odd code came from.  It's apparently been in
smallprint.{c,cc} forever.  I'm nuking it.  I see one potential problem
in fhandler_socket::bind.  It won't be hard to work around if that
function was really relying on it.

Thanks for tracking this down.  The change will be in the next snapshot.

cgf

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

Re: procps and pgrep hang

[Christopher Faylor]

On Wed, May 16, 2012 at 08:46:09PM -0500, Tom Rodman wrote:
>more details
>
># example hang (^C will not kill):
>
>  $ pgrep bash
>
># tail end of strace of above:
>
>   37  208960 [main] pgrep 2184 fhandler_process::exists: exists 
> (/proc/2488/cmdline)
>   41  209001 [main] pgrep 2184 build_fh_pc: fh 0x6127A350, dev 0xFE
>   38  209039 [main] pgrep 2184 fhandler_base::set_flags: flags 0x18000, 
> supplied_bin 0x0
>   33  209072 [main] pgrep 2184 fhandler_base::set_flags: O_TEXT/O_BINARY set 
> in flags 0x1
>   33  209105 [main] pgrep 2184 fhandler_base::set_flags: filemode set to 
> binary
>   65  209170 [main] pgrep 2184 open_shared: name cygpid.2488, n 2488, shared 
> 0xE1 (wanted 0x0), h 0x5FC, *m 6
>30704  239874 [main] pgrep 2184 fhandler_pipe::create: name 
>\\.\pipe\cygwin-dd7e5f3067f3e0da-2184-pipe-0xA, size 65536, mode 
>PIPE_TYPE_MESSAGE
>  155  240029 [main] pgrep 2184 fhandler_pipe::create: pipe read handle 0x5EC
>   48  240077 [main] pgrep 2184 fhandler_pipe::create: CreateFile: name 
> \\.\pipe\cygwin-dd7e5f3067f3e0da-2184-pipe-0xA
>   69  240146 [main] pgrep 2184 fhandler_pipe::create: pipe write handle 0x5E8
>   59  240205 [main] pgrep 2184 sig_send: sendsig 0x5F0, pid 2488, signal -36, 
> its_me 0
>
># procps example:
>
>   $ procps -o pid,args
>   PID COMMAND
>  4580 procps -o pid,args
>  --note: above command hangs, ended up killing it

Try a snapshot.

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

Re: Latest setup doesn't resolve dependencies

[Andrey Repin]

Greetings, Andrey Repin!

> This was a problem back in the years, when setup was actually doing this.
> It was nearly impossible to install a package with dependencies.
- install
+ uninstall


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 17.05.2012, <04:35>

Sorry for my terrible english...


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

[PATCH] fix broken mouse in Cygwin 1.7.14 and 1.7.15

[Mikulas Patocka]

On Thu, 17 May 2012, Mikulas Patocka wrote:

> > Corinna Vinschen:
> >
> > > 2012-04-03  Thomas Wolff
> > > 
> > >   * fhandler.h (class dev_console): Two flags for extended mouse modes.
> > >   * fhandler_console.cc (fhandler_console::read): Implemented 
> > >   extended mouse modes 1015 (urxvt, mintty, xterm) and 1006 (xterm).
> > >   Not implemented extended mouse mode 1005 (xterm, mintty).
> > >   Supporting mouse coordinates greater than 222 (each axis).
> > >   Also: two { wrap formatting consistency fixes.
> > >   (fhandler_console::char_command) Initialization of enhanced 
> > >   mouse reporting modes.
> > 
> > 
> > Patch applied with changes.  Please use __small_sprintf rather than
> > sprintf.  I also changed the CHangeLog entry slightly.  Keep it short
> > and in present tense.
> 
> Hi
> 
> The change (sprintf -> __small_sprintf) that Corinna applied actually 
> broke mouse reporting. It is broken in Cygwin 1.7.14 and 1.7.15.
> 
> When the user clicks with the first button, the mouse down event is 
> reported incorrectly, the mouse down event always looks like this:
>  1b 5b([) 4d(M) 30(0) 78(x) 32(2)
> Note that there is 0x30 (instead of 0x20) as the button. And there are 
> always fixed coordinates (0x78, 0x32), regardless of where the user 
> clicks.
> 
> This bug breaks the Links textmode browser (if you click on the top line, 
> you should see the menu, but you don't with Cygwin 1.7.14 and 1.7.15). It 
> also break Midnight Commander (if you start it with "TERM=xterm mc") and 
> all other programs that use xterm-style mouse reporting.
> 
> The reason is that __small_sprintf and sprintf aren't equivalent. 
> __small_sprintf processes '%c' format string differently from sprintf. A 
> piece of code from smallprint.cc:
> 
> case 'c':
>   {
> int c = va_arg (ap, int);
> if (c > ' ' && c <= 127)
>   *dst++ = c;
> else
>   {
> *dst++ = '0';
> *dst++ = 'x';
> dst = __rn (dst, 16, 0, c, len, pad, LMASK);
>   }
>   }
>   break;
> 
> We see that if the character is outside the range 0x21..0x7f, 
> __small_sprintf prints 0x and the hex value. On the other hand, sprintf 
> copies the byte unchanged.
> 
> __small_sprintf("%c", 32) doesn't print space, it prints 0x20 --- and this 
> breaks mouse click reporting. It also breaks the extended coordinate 
> reporting implemented by Thomas because it need to print characters >= 
> 0x80.
> 
> The attached patch fixes the mouse bug by changing __small_sprintf back to 
> sprintf. Alternatively, you can fix __small_sprintf to process "%c" 
> consistently with sprintf, but I don't know how much other code is 
> dependent on the current peculiar "%c" processing. So it's safer to change 
> mouse reporting calls to use sprintf.
> 
> Mikulas
> 
> ---
> 
> --- cygwin-1.7.14-2/winsup/cygwin/fhandler_console.cc_2012-05-17 
> 00:38:55.790039000 +0200
> +++ cygwin-1.7.14-2/winsup/cygwin/fhandler_console.cc 2012-05-17 
> 00:44:18.529296800 +0200
> @@ -625,17 +625,17 @@
>   /* We can now create the code. */
>   if (dev_state.ext_mouse_mode6)
> {
> - __small_sprintf (tmp, "\033[<%d;%d;%d%c", b,
> -  dev_state.dwMousePosition.X + 1,
> -  dev_state.dwMousePosition.Y + 1,
> -  mode6_term);
> + sprintf (tmp, "\033[<%d;%d;%d%c", b,
> +  dev_state.dwMousePosition.X + 1,
> +  dev_state.dwMousePosition.Y + 1,
> +  mode6_term);
>   nread = strlen (tmp);
> }
>   else if (dev_state.ext_mouse_mode15)
> {
> - __small_sprintf (tmp, "\033[%d;%d;%dM", b + 32,
> -  dev_state.dwMousePosition.X + 1,
> -  dev_state.dwMousePosition.Y + 1);
> + sprintf (tmp, "\033[%d;%d;%dM", b + 32,
> +  dev_state.dwMousePosition.X + 1,
> +  dev_state.dwMousePosition.Y + 1);
>   nread = strlen (tmp);
> }
>   else if (dev_state.ext_mouse_mode5)
> @@ -643,7 +643,7 @@
>   unsigned int xcode = dev_state.dwMousePosition.X + ' ' + 1;
>   unsigned int ycode = dev_state.dwMousePosition.Y + ' ' + 1;
>  
> - __small_sprintf (tmp, "\033[M%c", b + ' ');
> + sprintf (tmp, "\033[M%c", b + ' ');
>   nread = 4;
>   /* the neat nested encoding function of mintty 
>  does not compile in g++, so let's unfold it: */
> @@ -674,8 +674,8 @@
> xcode = 0;
>   if (ycode >= 256)
> ycode = 0;
> - __small_sprintf (tmp, "\033[M%c%c%c", b + ' ',
> -  xcode, ycode);
> + sprintf

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Chris Sutcliffe]

On 16 May 2012 16:24, marco atzeri wrote:
> On 5/16/2012 10:15 PM, Eric Blake wrote:
>> It isn't zlib (no binaries) or even zlib0 (cygcheck /usr/bin/cygz.dll
>> doesn't show libreadline 6 or 7).
>>
>> Why are we still linking against libreadline6 instead of libreadline7?
>> Is there a hint file that needs modification to fix the missing
>> dependency while we work on the bigger issue of getting the outdated
>> package built against a newer readline library?
>
> gpg depends on libreadline7
>
> I see no other readline dependency

Agreed, after installing libreadline6 and re-executing cygcheck I see
it no where in the dependency list, so I don't know why cygcheck was
complaining about it, but installing it resolved the cygcheck error
and I am now able to run gpg.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: [OT] "renaming file immediately after close fails" problem

[Thomas Wolff]

Am 16.05.2012 12:46, schrieb Václav Zeman:

Hi.

This is unrelated to Cygwin directly. I am having problems in my
library that renaming files sometimes fails right after the file is
closed. I vaguely remember seeing same or similar problems being
discussed in this mailing list but I cannot find the emails. Could any
of you remember discussions about this problem and its conclusions?


Just an idea: did you set any O_NDELAY or O_NONBLOCK flag on the file?

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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[marco atzeri]

On 5/16/2012 10:15 PM, Eric Blake wrote:

On 05/16/2012 02:08 PM, Chris Sutcliffe wrote:

On 16 May 2012 15:19, marco atzeri wrote:

On 5/16/2012 9:12 PM, Chris Sutcliffe wrote:

Every command / option I try with gpg comes back with a 'Bad address'
error:

$ gpg --version
mksh: gpg: Bad address

Am I missing something?


$ cygcheck gpg


Ah, should have thought of that. Turns out the culprit was a missing
dependency on libreadline6 (I believe as part of zlib).


It isn't zlib (no binaries) or even zlib0 (cygcheck /usr/bin/cygz.dll
doesn't show libreadline 6 or 7).

Why are we still linking against libreadline6 instead of libreadline7?
Is there a hint file that needs modification to fix the missing
dependency while we work on the bigger issue of getting the outdated
package built against a newer readline library?



gpg depends on libreadline7

I see no other readline dependency

Marco


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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Eric Blake]

On 05/16/2012 02:08 PM, Chris Sutcliffe wrote:
> On 16 May 2012 15:19, marco atzeri wrote:
>> On 5/16/2012 9:12 PM, Chris Sutcliffe wrote:
>>> Every command / option I try with gpg comes back with a 'Bad address'
>>> error:
>>>
>>> $ gpg --version
>>> mksh: gpg: Bad address
>>>
>>> Am I missing something?
>>
>> $ cygcheck gpg
> 
> Ah, should have thought of that. Turns out the culprit was a missing
> dependency on libreadline6 (I believe as part of zlib).

It isn't zlib (no binaries) or even zlib0 (cygcheck /usr/bin/cygz.dll
doesn't show libreadline 6 or 7).

Why are we still linking against libreadline6 instead of libreadline7?
Is there a hint file that needs modification to fix the missing
dependency while we work on the bigger issue of getting the outdated
package built against a newer readline library?

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Chris Sutcliffe]

On 16 May 2012 15:19, marco atzeri wrote:
> On 5/16/2012 9:12 PM, Chris Sutcliffe wrote:
>> Every command / option I try with gpg comes back with a 'Bad address'
>> error:
>>
>> $ gpg --version
>> mksh: gpg: Bad address
>>
>> Am I missing something?
>
> $ cygcheck gpg

Ah, should have thought of that. Turns out the culprit was a missing
dependency on libreadline6 (I believe as part of zlib).

Things seem to be fine now.

Cheers,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Chris Sutcliffe]

On 16 May 2012 15:19, Yaakov (Cygwin/X) wrote:
> On 2012-05-16 14:12, Chris Sutcliffe wrote:
>> Every command / option I try with gpg comes back with a 'Bad address'
>> error:
>>
>> $ gpg --version
>> mksh: gpg: Bad address
>>
>> Am I missing something?
>
> Is cygserver running?

Is it required?

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[marco atzeri]

On 5/16/2012 9:12 PM, Chris Sutcliffe wrote:

On 28 February 2012 10:02, marco atzeri wrote:

New version 1.4.12-1  of

gnupg

is available in the Cygwin distribution:


Every command / option I try with gpg comes back with a 'Bad address' error:

$ gpg --version
mksh: gpg: Bad address

Am I missing something?

Chris



$ gpg --version
gpg (GnuPG) 1.4.12
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ cygcheck gpg
Found: E:\cygwin\bin\gpg.exe
E:\cygwin\bin\gpg.exe
  E:\cygwin\bin\cygbz2-1.dll
E:\cygwin\bin\cygwin1.dll
[cut]
E:\cygwin\bin\cyggcc_s-1.dll
  E:\cygwin\bin\cygiconv-2.dll
  E:\cygwin\bin\cygintl-8.dll
  E:\cygwin\bin\cygreadline7.dll
E:\cygwin\bin\cygncursesw-10.dll
C:\Windows\system32\USER32.dll
[cut]
  E:\cygwin\bin\cygusb0.dll
C:\Windows\system32\cfgmgr32.dll
C:\Windows\system32\setupapi.dll
  C:\Windows\system32\OLEAUT32.dll
C:\Windows\system32\ole32.dll
  C:\Windows\system32\DEVOBJ.dll
  E:\cygwin\bin\cygz.dll




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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Yaakov (Cygwin/X)]

On 2012-05-16 14:12, Chris Sutcliffe wrote:

On 28 February 2012 10:02, marco atzeri wrote:

New version 1.4.12-1  of

gnupg

is available in the Cygwin distribution:


Every command / option I try with gpg comes back with a 'Bad address' error:

$ gpg --version
mksh: gpg: Bad address

Am I missing something?


Is cygserver running?


Yaakov

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

Re: [ANNOUNCEMENT] Updated: gnupg-1.4.12-1

[Chris Sutcliffe]

On 28 February 2012 10:02, marco atzeri wrote:
> New version 1.4.12-1  of
>
>        gnupg
>
> is available in the Cygwin distribution:

Every command / option I try with gpg comes back with a 'Bad address' error:

$ gpg --version
mksh: gpg: Bad address

Am I missing something?

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: Latest setup doesn't resolve dependencies

[marco atzeri]

On 5/16/2012 8:27 AM, Dr. Volker Zell wrote:

Hi

I'm on Windows 7 SP1 64 Bit with a complete new cygwin installation.  Today I
tried updating to the zlib and minizip combo. When I for example click on the
minizip package in the 'Not installed' page, according to the setup.hint file
the libminizip1 runtime file should be selected as well. But nothing
happens. Anybody else is seeing this ?


Ciao Volker



Hi Volker,
That feature was removed as if you select a package and than cancel it
there was no way to remove the added dependency, it was specifically a 
problem with chains of dependency that make impossible to recover the 
situation.


Dependency check is performed on the next step and it is proposed for
confirmation to user before download .

Ciao Marco


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

procps and pgrep

[Tom Rodman]

After upgrading to 1.7.15(0.260/5/3), on several hosts (but not all)
the commands:

  procps
  pgrep


hang.  I will try to follow up w/more details (cygcheck output)  in the next 
couple of days.

--
thanks,
Tom Rodman


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

RE: rxvt loses output connection with non cygwin console processes

[James Johnston]

> 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
> >nothing, and reports 30% cpu consumption
> 
> This problem should be fixed in the next snapshot.

Confirmed fixed with both my C test program and a .NET program too.


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

Re: "emacs -nw" hangs in a terminal

[Ken Brown]

On 5/15/2012 10:27 AM, Filipp Gunbin wrote:
[Ken Brown wrote:]

I can reproduce this on XP but not on Windows 7.  And I see from your
(partial) cygcheck output that you're running Vista.  I'll try to debug
this on my XP system.


I think I've fixed this, in both emacs-23 and emacs-24.  Please retest 
once I announce that the new releases have been uploaded (23.4-2 and 
24.0.96-2).


Thanks.

Ken


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

Re: rxvt loses output connection with non cygwin console processes

[Christopher Faylor]

On Wed, May 16, 2012 at 06:57:55AM -0400, Ken Brown wrote:
>On 5/15/2012 9:59 PM, Christopher Faylor wrote:
>> 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 nothing, and reports 30% cpu consumption
>>
>> This problem should be fixed in the next snapshot.
>>
>> Ken Brown, if you're reading this, would you mind confirming that the
>> problem with emacs and gdb -mi that I recently fixed has not been
>> resurrected?
>
>It's still fixed.

Thank you for confirming.

cgf

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

Re: [OT] "renaming file immediately after close fails" problem

[Earnie Boyd]

On Wed, May 16, 2012 at 8:15 AM, Václav Zeman wrote:
> On 16 May 2012 12:49, Nick Lowe wrote:
>> On Wed, May 16, 2012 at 11:46 AM, Václav Zeman wrote:
>>> Hi.
>>>
>>> This is unrelated to Cygwin directly. I am having problems in my
>>> library that renaming files sometimes fails right after the file is
>>> closed. I vaguely remember seeing same or similar problems being
>>> discussed in this mailing list but I cannot find the emails. Could any
>>> of you remember discussions about this problem and its conclusions?
>> Are you waiting for the file handle to become signalled before
>> attempting a rename?
>
> There is no file handle directly involved.

I suspect BLODA[2].

[1] http://cygwin.com/acronyms/#TOFU
[2] http://cygwin.com/faq/faq.using.html#faq.using.bloda

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

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

Re: [OT] "renaming file immediately after close fails" problem

[Václav Zeman]

On 16 May 2012 12:49, Nick Lowe wrote:
> Are you waiting for the file handle to become signalled before
> attempting a rename?
There is no file handle directly involved.

>
> Nick
>
> On Wed, May 16, 2012 at 11:46 AM, Václav Zeman  wrote:
>> Hi.
>>
>> This is unrelated to Cygwin directly. I am having problems in my
>> library that renaming files sometimes fails right after the file is
>> closed. I vaguely remember seeing same or similar problems being
>> discussed in this mailing list but I cannot find the emails. Could any
>> of you remember discussions about this problem and its conclusions?

-- 
VZ

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

Re: Latest setup doesn't resolve dependencies

[Andrey Repin]

Greetings, Dr. Volker Zell!

> I'm on Windows 7 SP1 64 Bit with a complete new cygwin installation.  Today I
> tried updating to the zlib and minizip combo. When I for example click on the
> minizip package in the 'Not installed' page, according to the setup.hint file
> the libminizip1 runtime file should be selected as well.

It will be, when you try to install it.

> But nothing happens. Anybody else is seeing this ?

This was a problem back in the years, when setup was actually doing this.
It was nearly impossible to install a package with dependencies.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.05.2012, <15:31>

Sorry for my terrible english...


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

Re: ssh error

[Andrey Repin]

Greetings, Lars Bjшrndal!

> After updating to latest cygwin today on a Win7 64-bit system, I got an
> error when starting ssh: "bash: Bad address". Where does that error come
> from?

ssh -vv

?


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.05.2012, <15:33>

Sorry for my terrible english...

Re: rxvt loses output connection with non cygwin console processes

[Ken Brown]

On 5/15/2012 9:59 PM, Christopher Faylor wrote:

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 nothing, and reports 30% cpu consumption


This problem should be fixed in the next snapshot.

Ken Brown, if you're reading this, would you mind confirming that the
problem with emacs and gdb -mi that I recently fixed is has not been
resurrected?


It's still fixed.

Ken


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

ssh error

[Lars Bjørndal]

After updating to latest cygwin today on a Win7 64-bit system, I got an
error when starting ssh: "bash: Bad address". Where does that error come
from?

Lars

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

Re: [OT] "renaming file immediately after close fails" problem

[Nick Lowe]

Are you waiting for the file handle to become signalled before
attempting a rename?

Nick

On Wed, May 16, 2012 at 11:46 AM, Václav Zeman  wrote:
> Hi.
>
> This is unrelated to Cygwin directly. I am having problems in my
> library that renaming files sometimes fails right after the file is
> closed. I vaguely remember seeing same or similar problems being
> discussed in this mailing list but I cannot find the emails. Could any
> of you remember discussions about this problem and its conclusions?
>
> --
> VZ
>
> --
> 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
>

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

[OT] "renaming file immediately after close fails" problem

[Václav Zeman]

Hi.

This is unrelated to Cygwin directly. I am having problems in my
library that renaming files sometimes fails right after the file is
closed. I vaguely remember seeing same or similar problems being
discussed in this mailing list but I cannot find the emails. Could any
of you remember discussions about this problem and its conclusions?

-- 
VZ

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