Re: Cygwin 1.7.1-1 - problem with non-blocking socket IO

On Dec 29 01:11, Larry Hall (Cygwin) wrote: > On 12/29/2009 01:07 AM, Uri Simchoni wrote: > >Thanks for the quick response. Could you post the patch? > > See the cygwin-cvs mailing list for applied patches to Cygwin. In this case: > Tonight

Re: setup 1.7.1 hangs on 000-cygwin-post-install.sh

Frank Fesevur users.sourceforge.net> writes: > Didn't help either. I upgraded at home without any problem. I haven't > got a clue how to get cygwin back on my system I'm experiencing the same problems. Fortunately, the "legacy install" (aka 1.5) works like a charm. hth, -tt -- Problem repor

Re: gcc4[1.7] printf treats differently a string constant and a character array

>2009/12/28 Andy Koppe: >... >Ah, the problem actually is that your program is missing a call to >setlocale(LC_CTYPE, "") to switch to the locale and character set >specified in the environment... That worked!, but what that means is that if one wants to use any locale other than C.UTF-8, one has,

Re: gcc4[1.7] printf treats differently a string constant and a character array

2009/12/29 Rodrigo Medina: >>Ah, the problem actually is that your program is missing a call to >>setlocale(LC_CTYPE, "") to switch to the locale and character set >>specified in the environment... > > That worked!, but what that means is that if one wants to > use any locale other than C.UTF-8, on

Re: gcc4[1.7] printf treats differently a string constant and a character array

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andy Koppe on 12/28/2009 11:17 PM: >>> I am using LC_ALL=es_VE.ISO-8859-15. So you told gcc which charset to use for those non-ASCII characters, which resulted in raw 8-bit bytes. puts is required to work transparently on bytes, but prin

Re: gcc4[1.7] printf treats differently a string constant and a character array

2009/12/29 Eric Blake: >> I couldn't find specific text about invalid bytes in the POSIX printf >> spec, > > http://www.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > > "all forms of fprintf() shall fail if: > > [EILSEQ] >    [CX] A wide-character code that does not correspond to a va

Re: No go after update to 1.7.1

On Mon, Dec 28, 2009 at 11:30 AM, Bernd Bartmann wrote: > On Mon, Dec 28, 2009 at 12:31 AM, Christopher Faylor > wrote: >> I'd suggest at this point that you run sysinternals procmon to see if >> you can figure out why bash isn't starting.  You might also try running >> with a trimmed down PATH. >

[Patch] chere-1.1-1: fix uninstall from Control Panel

Uninstalling a chere item from Control Panel does not work if C:\cygwin\bin is not in Windows default PATH. The attached patch fixes this. Christian --- chere-1.1-1 2009-01-29 23:15:52.00100 +0100 +++ chere 2009-12-29 14:09:58.046875000 +0100 @@ -707,7 +707,7 @@ create_uninstall_item() #

Re: gcc4[1.7] printf treats differently a string constant and a character array

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andy Koppe on 12/29/2009 6:30 AM: >> Remember, POSIX states that any use in a character context of bytes with >> the 8th-bit set is specifically undefined in the C locale (whether that be >> C.ASCII or C.UTF-8). > > I very much disagree w

"update-desktop-database" seems to not work anymore.

Hello, - Just to report that "update-desktop-database" seems to not work correctly on Cygwin 1.7.1. It was working on Cygwin 1.5.x. - Furthermore, I notice the following things: - On Cygwin, when calling "update-desktop-database" without parameter, "update-desktop-database"

Re: [ANNOUNCEMENT] Updated: cygutils-1.4.2-1

2009/12/29 Charles Wilson: > TODO (call for patches): > > * Update lpr.cc and mkshortcut.c to use cygwin-1.7 cygwin_conv_path >  instead of deprecated cygwin_conv_to_win32_path. I'll have a go at mkshortcut. Andy -- Problem reports: http://cygwin.com/proble

Re: No go after update to 1.7.1

Obviously my last post didn't make it through the mailing list probably because of a .csv attachment. So, here's the original text again: Setting the PATH to C:\cygwin\bin only doesn't help either. So I tried procmon to monitor what bash is actually doing. As it seems it stops because it can't fin

Re: "update-desktop-database" seems to not work anymore.

On 12/29/2009 10:21 AM, Claude Sylvain wrote: - Cygwin "setup" do not show any "update-desktop-database" package!? So, it is difficult to go further more in the evaluation/resolution of that problem. cygcheck -p update-desktop-database -- Larry Hall

Re: No go after update to 1.7.1

On 12/29/2009 10:57 AM, Bernd Bartmann wrote: Obviously my last post didn't make it through the mailing list probably because of a .csv attachment. So, here's the original text again: Setting the PATH to C:\cygwin\bin only doesn't help either. So I tried procmon to monitor what bash is actually

Re: Fwd: No go after update to 1.7.1

[ Cc'ing the list back in now, FTR. ] Bernd Bartmann wrote: >> Looks like your post didn't make it through to the list; there's nothing in >> the archive for your message with ID >> <6c18a4f0912280230k601eca9me32c056e09117...@mail.gmail.com>. Probably >> something somewhere down the line though

Re: No go after update to 1.7.1

Bernd Bartmann wrote: > > procmon to monitor what bash is actually doing. As it seems it stops > because it can't find /etc/passwd and /etc/fstab which indeed are > missing. Shouldn't they have been created during the setup process? > Also, /etc does not contain any files just some sub-directorie

Re: "update-desktop-database" seems to not work anymore.

Claude Sylvain wrote: - Just to report that "update-desktop-database" seems to not work correctly on Cygwin 1.7.1. update-desktop-database.exe seems to be affected by a bug in Cygwin's libtool. See: Libtool: Generated manifests need execute permission http://article.gmane.org/gmane.os.cyg

cygpath and spaces in filenames when reading from a file

Hi, cygpath can read a list of paths to convert from a file, when started with -file. However, how do you specify paths with spaces in them in this mode? It seems quoting the path or using \ doesn't seem to work. E.g: $cygpath --windows --file - "/usr/local/my dir/" "\usr\local\my dir\" $ cygpat

Re: Fwd: No go after update to 1.7.1

On Tue, Dec 29, 2009 at 6:05 PM, Dave Korn wrote: >  We have a suspect: > >> "11:09:08,3362588","bash.exe","3396","CreateFileMapping","C:\Programme\BitDefender\BitDefender >> 2010\Active Virus Control\midas32-v2_58\PLUGIN_NT.M32","SUCCESS","SyncType: >> SyncTypeOther" > >  That's listed on BLODA.

Re: git stopped working with 1.7.1

David Antliff wrote: >> > It may be a 64-bit issue, so I'll try a 32-bit machine, if I can >> > scrounge one up. >> >> We are using WinXP 32-bit and have not seen this problem (yet). It >> would be really helpful (to me at least) to know whether you can >> reproduce the issue with 32-bit Windows

Re: Fwd: No go after update to 1.7.1

Bernd Bartmann wrote: > Now how to go on to get the cygwin installation fixed? As Larry > pointed out - because bash could not be run during the setup process > the postinstall scripts couldn't be run. > Shall I just reinstall all packages but the core cygwin package? Take a look in /etc/postin

Re: "update-desktop-database" seems to not work anymore.

Cesar Strauss wrote: > > Claude Sylvain wrote: > >> - Just to report that "update-desktop-database" seems to not work >> correctly on Cygwin 1.7.1. > > update-desktop-database.exe seems to be affected by a bug in Cygwin's > libtool. > > See: > Libtool: Generated manifests need execute permissio

Re: Fwd: No go after update to 1.7.1

On Tue, Dec 29, 2009 at 06:08:50PM +, Dave Korn wrote: >Of course, this means that it's all someone else's fault and Cygwin is >perfect :-) and I'm not saying that under any kind of duress or >gravitationally-inspired threat from any kind of even-toed aquatic >ungulant whatsoever ... Gentlemen

Re: A question about setup.exe

Paul McFerrin wrote: > OKAY... I finally realized that MTIME was not used by setup. I now have > my installation completely restored. I used file > /etc/setup/installed.db to "trick" setup to do a forced install. > > 1. Have a running cygwin system available > 2. Run "setup" thru the "Package Se

Re: Fwd: No go after update to 1.7.1

On Tue, Dec 29, 2009 at 7:08 PM, Dave Korn wrote: >  Take a look in /etc/postinstall.  If you see lots of files named "*.sh", > then you can simply re-run setup.exe and click right through it without > changing any of the settings from last time and it will finish off running any > scripts that it

Re: make-3.81-4

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

Bash v4.0 does not respect $PATH

Folks, I need associative arrays so I got the bash 4.0 source, compiled it under cygwin and installed it in /usr/local/bin. I have ActiveState perl installed in /opt/perl which preceeds /usr/local/bin:/bin:/usr/bin on my path. Using bash 4.0, 'which' says I should get ActiveState perl, but actua

Re: git stopped working with 1.7.1

On Thu, Dec 24, 2009 at 07:55, Kevin Layer wrote: >  la...@hobart128 /c/tmp >  $ git clone git:/repo/git/acl acl.test >  Initialized empty Git repository in /c/tmp/acl.test/.git/ >  remote: Counting objects: 9205, done. >  remote: Compressing objects: 100% (3300/3300), done. >  fatal: The remote e

Re: Cygwin 1.7.1-1 - problem with non-blocking socket IO

On Dec 29 09:30, Corinna Vinschen wrote: > On Dec 29 01:11, Larry Hall (Cygwin) wrote: > > On 12/29/2009 01:07 AM, Uri Simchoni wrote: > > >Thanks for the quick response. Could you post the patch? > > > > See the cygwin-cvs mailing list for applied patches to Cygwin. In this > > case: > >

Alt key not recognized as Meta in xterm

With the upgrade to Cygwin 1.7, I found that the Alt key is no longer recognized as a Meta key in xterm. This means the Alt based command line editing keys such as Alt-F/B for forward- and backward-word must be entered with the Esc key instead. I assume this is related to the internationalization c

Re: make-3.81-4

Edward Lam wrote: 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

RE: "mount -a" has no effect on the cygdrive prefix

> Date: Thu, 24 Dec 2009 12:10:47 +0100 > From: corinna-cygwin > Subject: Re: "mount -a" has no effect on the cygdrive prefix > > On Dec 23 08:32, Karl M wrote: >> Hi All... >> >> With the last 1.7.0 version and with a clean 1.7.1 install on an XP Pro SP3 >> machine, >> if I edit my fstab to chan

Re: Bash v4.0 does not respect $PATH

On Tue, Dec 29, 2009 at 11:21 PM, Neil Mowbray wrote: > Folks, > > I need associative arrays so I got the bash 4.0 source, compiled it under > cygwin and installed it in /usr/local/bin. > > I have ActiveState perl installed in /opt/perl which preceeds > /usr/local/bin:/bin:/usr/bin > on my path.  

Re: make-3.81-4

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

High CPU consumption with git tab completion in zsh

I've noticed that using tab completion with git in zsh often causes zsh to consume 100% of my CPU for around ten minutes before the completion request completes. The zsh completion commands look rather old: , | % ls -l /usr/share/zsh/4.3.9/functions | egrep git | -rwxr-x---+ 1 seh Users618

Defeated by "alternatives": unison

Since updating my Cygwin installation to version 1.7, I can no longer run "unison" from the command line. Unison uses the "alternatives" facility to select among multiple installed versions. The symbolic links all look to be set up properly, but the program can't be invoked in the normal ways. I'v

Re: Defeated by "alternatives": unison

On 12/29/2009 09:28 PM, Steven E. Harris wrote: Since updating my Cygwin installation to version 1.7, I can no longer run "unison" from the command line. Unison uses the "alternatives" facility to select among multiple installed versions. The symbolic links all look to be set up properly, but the

Can't use key authentication on x64 Server 2003 R2

Since upgrading to Cygwin 1.7, I'm no longer able to use key authentication on one of several Windows systems. All of the working systems are 32 bit installs, the one which isn't working is 64 bit. The problem only affects key authentication. Password authentication still works properly. T

Goldstar please (Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2)

On Tue, Dec 29, 2009 at 07:31:07PM -0500, Charles Wilson wrote: >Yaakov (Cygwin/X) wrote: >> On 29/12/2009 16:27, Charles Wilson wrote: >>> Sounds like a good idea, but I wish I'd known this was coming before >>> wasting time on: >>> >>> * Improve checkX behavior when used as 'barrier' in