Re: HEADSUP: Packages with obsolete dependencies
2009/12/27 Yaakov (Cygwin/X): This is a list of packages which depend on obsolete library versions. Some of these libraries have serious bugs (e.g. libncurses7 is not rebaseable). This list does not reflect dependencies on libintl3, libjpeg62, or libncurses8, as they were more recently obsoleted and many packages still use them. Maintainers, please update or rebuild these packages with the newest dependencies, and be sure to update your setup.hint files as well. icu (gcc4-runtime) Thanks for the headsup. Done. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
default /etc/fstab contains dead link
The /etc/postinstall/000-cygwin-post-install.sh script places a dead link into /etc/fstab: # http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table The 1.7 needs to be dropped from that path, or perhaps a symlink should be created on the web server? Andy
Re: default /etc/fstab contains dead link
On Dec 29 15:56, Andy Koppe wrote: The /etc/postinstall/000-cygwin-post-install.sh script places a dead link into /etc/fstab: # http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table The 1.7 needs to be dropped from that path, or perhaps a symlink should be created on the web server? Thanks for the hint. I updated the base-cygwin package and added a redirection to the web server. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFU: spamprobe-1.4d-2 (libungif4)
Corinna Vinschen libungif4 has been obsoleted by libgif4, part of the giflib package. Install giflib/libgif4/libgif-devel, uninstall libungif/libungif4/ libungif-devel and rebuild. Ok, rebuilt for 1.7 with libgif: wget \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2.tar.bz2 Jari
Re: RFU: spamprobe-1.4d-2 (libungif4)
On 29/12/2009 17:22, Jari Aalto wrote: Ok, rebuilt for 1.7 with libgif: wget \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2.tar.bz2 I'm getting 404s on the tarballs. Yaakov
Re: RFU: spamprobe-1.4d-2 (libungif4)
Yaakov (Cygwin/X) wget \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/spamprobe/spamprobe-1.4d-2.tar.bz2 I'm getting 404s on the tarballs. Fixed now. Thanks, Jari
Re: X server fails to start
Charles Wilson cygwin at cwilson.fastmail.fm writes: I guess I should be specific: that's checkX from the run2-0.4.0-1 package, which should begin hitting the mirrors soon. -- Chuck I downloaded latest run2-0.4.0-1. One of machine is still failing. one Windows 7 and another XP work though. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xinit-1.2.0-2
The following package has been updated in the Cygwin distribution: * xinit-1.2.0-2 This package includes the startx, startxdmcp.bat, and startxwin commands for launching the XWin server. IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER SUPPORTED. This release replaces those scripts with a startxwin executable. By default, startxwin will launch an XWin server in multiwindow mode together with an xterm. A $HOME/.startxwinrc file can be created with a list of commands for startxwin to launch instead of an xterm. startxwin also accepts command line arguments to use a different DISPLAY number and add additional options to pass to the server. Please read the startxwin(1) manpage, which describes both the command-line arguments accepted by startxwin and the format of the $HOME/.startxwinrc file. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xinit-1.2.0-2
On Tue, Dec 29, 2009 at 1:57 PM, Yaakov (Cygwin/X) wrote: This release replaces those scripts with a startxwin executable. Should we use run to launch startxwin.exe, or is it OK to just create a shortcut to startxwin.exe? - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
Yaakov (Cygwin/X) wrote: IMPORTANT: THE startxwin.bat AND startxwin.sh SCRIPTS ARE NO LONGER SUPPORTED. This release replaces those scripts with a startxwin executable. facepalm! Sounds like a good idea, but I wish I'd known this was coming before wasting time on: 2009-12-29 run2-0.4.0 (release) ... * Improve checkX behavior when used as 'barrier' in startxwin. ... Oh, well. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xinit-1.2.0-2
On 29/12/2009 16:15, Jim Reisert AD1C wrote: Should we use run to launch startxwin.exe, or is it OK to just create a shortcut to startxwin.exe? In general, you should be using run.exe in Windows shortcuts. The Start Menu shortcut created during postinstall goes a step further, running: \path\to\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe IOW startxwin is launched from within a login shell so that it knows where to find HOME (for .startxwinrc) and so that clients launched thereby inherit a complete user environment. Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
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 startxwin. Sorry about that, Chuck, but this was just the latest of a long string of issues involving these scripts. We've been talking about replacing them for a while, and the recent traffic on the list was enough of an impetus to make me finally stop bandaging the scripts and find a better solution. Plus, we gain argument handling and .startxwinrc, something the scripts would likely never do. Honestly, this wasn't even checkX's fault, so we weren't expecting you to fix it. The real problem here is a corner-case bug in the server; the race condition that checkX was causing was just the trigger. We still need to get to the bottom of that, but in the meantime we have a solution that completely avoids the problem and gives us new features to boot. Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xinit-1.2.0-2
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 startxwin. Sorry about that, Chuck, but this was just the latest of a long string of issues involving these scripts. We've been talking about replacing them for a while, and the recent traffic on the list was enough of an impetus to make me finally stop bandaging the scripts and find a better solution. Plus, we gain argument handling and .startxwinrc, something the scripts would likely never do. Like I said, it sounds to me like a good idea; there's just so many issues that can go (and have gone) wrong in these scripts -- PLUS, whose idea was it to have TWO, one .sh and one .bat?!!? Yeeesh. We're well rid of them. Honestly, this wasn't even checkX's fault, so we weren't expecting you to fix it. The real problem here is a corner-case bug in the server; the race condition that checkX was causing was just the trigger. We still need to get to the bottom of that, but in the meantime we have a solution that completely avoids the problem and gives us new features to boot. Yes, it definitely seemed like some sort of race going on -- I even noticed sometimes that checkX would return success (e.g. was able to call XOpenDisplay()), but that the very next command in my startxwin.sh script would fail with a can't open display error. Err...what? So, yeah, I think startxwin.exe/.startxwinrc is a really excellent step forward. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: What is correct way to start xterm from .XWinrc?
On Wed, Oct 28, 2009 at 9:17 AM, Jim Reisert AD1C jjreis...@alum.mit.edu wrote: My .XWinrc file has this menu line: xterm EXEC xterm -e tcsh Since my default shell in /etc/passwd is /bin/tcsh, why should I need to specify it here also? If I don't specify it, a new xterm doesn't execute my ~/.cshrc file. I do not have a ~/.login or ~/.profile file. What is the right way to do this? Using the new startwin.exe in my Startup folder shortcut: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe My .XWinrc now has simply: xterm EXEC xterm -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin 1.7 beta XWin Crashs from Ubuntun 9.10 after Firefox sessions (update)
After I upgraded to xorg-server1.7.3-1, XWin does not crash anymore after I ssh to Ubuntun 9.10 invoking gnome-session. But it hangs intermittently after a few Firefox sessions and I need to terminate XWin. Hope the next xorg-server upgrade will improve this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
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: http://cygwin.com/ml/cygwin-cvs/2009-q4/msg00150.html Tonight (yes, unfortunately) it occured to me that the patch isn't quite correct, yet. I haven't much time, what with vacation and all that, but I know what has to be changed. I'll come up with a better solution in the next couple of days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 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, not only to compile again the programs , but also to modify them. Perhaps the best thing to do is to read the LC_ALL variable from the environment and then call setlocale. Thanks RM -- 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: 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, one has, not only to compile again the
programs , but also to modify them. Perhaps the best thing to do
is to read the LC_ALL variable from the environment and then call
setlocale.
setlocale(LC_CTYPE, ) already does that. It tries to read LC_ALL,
LC_CTYPE, and LANG, in that order, and only if none of them are set it
falls back to the default locale: C.UTF-8.
'char' string constants with non-ASCII characters are not a good idea
if the program is supposed to work with different charsets, because
they're encoded in one particular charset, namely that of your editor.
In that case you need to use wchar_t strings instead, for example:
#include locale.h
#include wchar.h
int main(void) {
setlocale(LC_CTYPE, );
wprintf(LØl\n);
}
You also need to ensure that gcc's character set matches the source
file's; otherwise gcc won't encode the wide string correctly.
Andy
--
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: 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 printf is specified as a mix between bytes (arguments matching %s) and characters (the format string itself, and arguments matching %ls). 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. In fact, since your program contains hard-coded ISO-8859-15 strings, you should probably do setlocale(LC_CTYPE, whatever.ISO-8859-15). Well, as long as you are running it on your machine, with LC_ALL=es_VE.ISO-8859-15 in the environment, then setlocale(LC_ALL,) will pick up the same charset as what gcc hard-coded into your app. But yes, by using 8-bit bytes in your string, you have married your executable to a particular locale, and it is no longer portable to machines using a different charset. To be more portable, you would want to use some iconv() conversions (or look into using gettext() for translation catalogs). Without a setlocale call, programs use the C locale, and on Cygwin 1.7 that implies the UTF-8 character set. Those single accented ISO-8859-15 characters are invalid when interpreted as UTF-8, so printf halts there. The accented character pairs like á, meanwhile, happen to be valid UTF-8, so they get through. 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 valid character has been detected. It's talking about characters rather than bytes there, which I think does leave the behaviour for invalid bytes undefined, It's actually well-defined - non-characters in the format string MUST make printf fail. However, it raises the issue of whether the failure must occur without any output, or only upon detection of the first invalid character whether or not prior characters and % directives have been acted upon. I think the standard is silent on that point, making it a QoI issue. 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). Using accented characters (which result in bytes with the 8th-bit set, whether you use UTF-8 or ISO-8859-15) falls into that category, so the bug is in your program for expecting sane results while not changing the locale away from C. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6AkYACgkQ84KuGfSFAYCcZwCfSqNz9qdjxEBXHMwtPJ+8bx9T 6S4AoJlgfarKywPgDH6TY3Zy16/3jc1K =YRTJ -END PGP SIGNATURE- -- 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: 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 valid character has been detected. The issue wasn't with wide characters, but invalid multibyte chars. But anyway, we're agreed that printf is right to bail out. 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 with that. C.ASCII and C.UTF-8 are different locales from plain C, and the whole point of the explicitly stated charset is to define the meaning of bytes beyond 7-bit ASCII. Andy -- 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: 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 cgf-use-the-mailinglist-ple...@cygwin.com 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. 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 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-directories: alternatives defaults fonts postinstall preremove profile.d setup terminfo I've attached the procmon log for the bash start test in .csv format for your inspection. Maybe also of interest is /var/log/setup.log. No one? No more ideas? Best regards, Bernd. -- 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] 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() # even after the cygwin directory is wiped :( if $REGTOOL add $1 ; then $REGTOOL -s set $1/DisplayName \$CPH_DESC\ - $REGTOOL -s set $1/UnInstallString \$ASH_EXE -c \\\/bin/chere $UINST_ARG -u -s $2 + $REGTOOL -s set $1/UnInstallString \$ASH_EXE -c \\\PATH=/bin /bin/chere $UINST_ARG -u -s $2 else echo $0 Error: Couldn\'t modify HKLM hive. echo Control Panel uninstall will not be available. -- 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: 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 with that. C.ASCII and C.UTF-8 are different locales from plain C, and the whole point of the explicitly stated charset is to define the meaning of bytes beyond 7-bit ASCII. Point taken: an explicit C.UTF-8 is a request of a specific charset along with C semantics (such as no translation of output messages, posix-mandated formatting for time and money, ...), but because the charset is explicit, the use of 8-bit bytes is well-defined in our implementation (and since POSIX does not specify C.UTF-8, you've already left the realm of portability and gone into implementation-defined). But my point remains: an explicit C is specified to be charset-agnostic, so a portable program requesting C should not be expecting any particular behavior of 8-bit bytes in character contexts. Programs that use LC_ALL=C to try to get 8-bit transparency from character contexts are flat-out non-portable. They get other well-defined benefits on 8-bit bytes (such as sorting by strcmp instead of strcoll, fixed-format messages, ...), but only insofar as those 8-bit bytes are in byte contexts rather than character contexts. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6Bw0ACgkQ84KuGfSFAYByhQCZAWbgggdJm5KBtBfNm9ElHmJN p14AoMoKgy2XxhNqnV/KxuFVyttbp+m6 =eLYn -END PGP SIGNATURE- -- 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
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 exit silently!? On a Slackware 12.1 GNU/Linux machine, calling update-desktop-database without parameter make it display the following message No directories in update-desktop-database search path could be processed and updated. - On Cygwin and on a Slackware 12.1 GNU/Linux machine, there is no man page for update-desktop-database. - On Cygwin, update-desktop-database do not display help when calling it with -? or --help parameters. These parameters work correctly on a Slackware 12.1 GNU/Linux machine. - On Cygwin, update-desktop-database seems to always return a a value of 127. On a Slackware 12.1 GNU/Linux machine, update-desktop-database return a value of 1 when it fail. - Remarks: - This problem make installation to fail when doing make install on some projects; like geda-gaf project. - The workaround I used to get rid of that problem is to replace the call to update-desktop-database by something like ls in the Makefile created by the autotools. - 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. From a Cygwin user. Claude -- 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: 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/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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 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-directories: alternatives defaults fonts postinstall preremove profile.d setup terminfo As mailing list doesn't seem to like the procmon log in .csv format I'll not attach it again. I can send it to a private email address by request. Best regards, Bernd. -- 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: 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 http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: 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 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-directories: alternatives defaults fonts postinstall preremove profile.d setup terminfo So this means your installation isn't proceeding properly. Could be failed postinstall scripts, perhaps as a result of bash not being able to run. You can check out '/var/log/setup.log.full' for some insights. Also, I think it's time to start considering the possible effects of BLODA http://cygwin.com/acronyms/#BLODA. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: 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 thought a .csv attachment was suspicious, malicious, spammy-looking or overly-large, so I'm writing off-list to ask for a copy. Can't promise it'll show anything, but I'll take a look. Thanks Dave for pointing this out. Below you'll find my original post. Hopefully the attachments will arrive as well. 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. You may be able to work around by following the rebase advice discussed in these threads: BitDefender again http://www.cygwin.com/ml/cygwin/2009-08/threads.html#00771 http://www.cygwin.com/ml/cygwin/2009-09/threads.html#9 Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes http://cygwin.com/ml/cygwin/2009-12/threads.html#00159 (I left a question unanswered in one of those threads about what the effects of relocating the cygwin1 dll to a low base address could be; the brief answer would be largely theoretical, unless you're the type who does massive number crunching with huge arrays in fortran, or similar.) cheers, DaveK -- 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: 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-directories: - Last week I installed (using setup.exe) Cygwin 1.7.1, and none of the problems that you describe above appear. - This lead me to think that you have not configured setup.exe correctly. Either you choose a mirror site that do not contain all Cygwin element, or you have not selected the packages correctly. - When I have installed Cygwin 1.7.1, I have done the following things: - Renamed the old Cygwin (1.5.x) directory C:\cygwin as C:\cygwin_old. Just be able to recover by personnal data, later. - Downloaded the latest version Cygwin setup.exe in a newly created temporary directory. - Launched setup.exe, and configure it something like: - Selected ftp://mirrors.kernel.org; as the mirror site. Note: Some mirrors sites seems to do not have all necessary Cygwin packages to make a good installation!? But the one mentionned above is a good choice. - Selected all the packages, by choosing install on all in Category field. Note: As stated in http://cygwin.com/cygwin-ug-net/index.html;, this make a huge installation. But, everything is there! Hope it will help. From a Cygwin user. Claude. -- 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: 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.cygwin/110870 When compiling update-desktop-database.exe, libtool first creates a wrapper executable with the same name, for internal purposes. To defeat UAC, it also creates a manifest file. Unfortunately, it fails to set the execute bit, so the wrapper is non-functional. As a result, the libtool wrapper ends up being installed and packaged, instead of the real program. For a detailed description and test case, see the post referenced above. - This problem make installation to fail when doing make install on some projects; like geda-gaf project. Coincidentally, it was the very project that lead me to investigate the issue. - The workaround I used to get rid of that problem is to replace the call to update-desktop-database by something like ls in the Makefile created by the autotools. Just use ./configure --disable-update-xdg-database Cesar -- 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
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\ $ cygpath --windows --file - /usr/local/my\ dir/ C:\cygwin\usr\local\my\ dir\ Cheers, Jon -- 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: git stopped working with 1.7.1
David Antliff david.antl...@gmail.com 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... I imagine there are a fair number of people using git in Cygwin because the Windows alternatives (msys, etc) do not provide a POSIX-like toolchain environment. Using Cygwin also allows scripts around git to operate on Linux with no modifications. That is why we use Cygwin anyway, and Cygwin + git is very important to us, FWIW. I just tried 32-bit Windows XP Pro. I upgraded from 1.5.25 and installed git (it wasn't previously on that machine). Failed the same way. Kevin -- 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: 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/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 didn't do last time. OTOH, if you see only lots of files named *.sh.done, that means it somehow didn't notice that the scripts had failed and it won't try re-running them; in that case, you still re-run setup.exe and click through it largely unaltered, but when you get to the package chooser screen, select the category view and set the top category to reinstall. Also, it is not entirely clear to me if cygwin or BitDefender is to blame for the problem. Is there work going on to address this issue from the cygwin side? Should I contact BitDefender about the problem? I would regret it if cygwin can't be installed by Joe User on a system that has BitDefender 2010 installed as well. To a large extent, it's one of those 'can't-be-helped' things: - To mimic posix fork semantics, Cygwin has to recreate the exact memory map of the parent process in the child's memory space, including the addresses at which shared libraries (dlls) are loaded. - To intercept file access and check for viruses etc., BitDefender injects dlls into every process to hook the potentially-dangerous system calls. - Cygwin doesn't actually have full control over how things get loaded into memory; that's determined by the OS loader which is invoked when Cygwin calls CreateProcess. - Sometimes the OS loader doesn't reload all the DLLs in the newly-created child process at the same base addresses as they were at in the parent process when there's a clash between two DLLs competing for the same base address. There are some tricks in the DLL to try and avoid and/or work around the problem, but ultimately we're limited by the behaviour of the underlying OS which isn't directly under our control and doesn't always do what is needed for POSIX semantics because (after all) it was designed to implement win32 semantics. 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 ... cheers, DaveK -- 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: 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 permission http://article.gmane.org/gmane.os.cygwin/110870 When compiling update-desktop-database.exe, libtool first creates a wrapper executable with the same name, for internal purposes. To defeat UAC, it also creates a manifest file. Unfortunately, it fails to set the execute bit, so the wrapper is non-functional. As a result, the libtool wrapper ends up being installed and packaged, instead of the real program. For a detailed description and test case, see the post referenced above. - This problem make installation to fail when doing make install on some projects; like geda-gaf project. Coincidentally, it was the very project that lead me to investigate the issue. - The workaround I used to get rid of that problem is to replace the call to update-desktop-database by something like ls in the Makefile created by the autotools. Just use ./configure --disable-update-xdg-database Thank you for your advice. Your workaround is far much better than mine. Claude. -- 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: 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, please stand down. There will be no hippo launching today. 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: 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 Selection pages but NOT beyond 3. On your running cygwin system, delete all but 1st line in file /etc/setup/installed.db. 4. Shutdown your running cygwin sysrem 5. Click the NEXT button in setup and your re-installation will begin. Oh, I didn't see this post earlier. I prefer to do it the easy way: 2. Run setup thru the Package Selection pages but NOT beyond 3. Select Reinstall at the top-level of the category view. 5. Click the NEXT button in setup and your re-installation will begin. cheers, DaveK -- 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: 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 didn't do last time. OTOH, if you see only lots of files named *.sh.done, that means it somehow didn't notice that the scripts had failed and it won't try re-running them; in that case, you still re-run setup.exe and click through it largely unaltered, but when you get to the package chooser screen, select the category view and set the top category to reinstall. After noticing that all files in the /etc/postinstall dir are named *.sh.done I chose your second option. This worked fine and now my /etc dir is filled correctly. But I should note that of course one has to omit the cygwin-1.7.1-1 package from the reinstall process as this will again install the DLL that has not been rebased and thus all postinstall scripts will fail again. To a large extent, it's one of those 'can't-be-helped' things: - To mimic posix fork semantics, Cygwin has to recreate the exact memory map of the parent process in the child's memory space, including the addresses at which shared libraries (dlls) are loaded. - To intercept file access and check for viruses etc., BitDefender injects dlls into every process to hook the potentially-dangerous system calls. - Cygwin doesn't actually have full control over how things get loaded into memory; that's determined by the OS loader which is invoked when Cygwin calls CreateProcess. - Sometimes the OS loader doesn't reload all the DLLs in the newly-created child process at the same base addresses as they were at in the parent process when there's a clash between two DLLs competing for the same base address. There are some tricks in the DLL to try and avoid and/or work around the problem, but ultimately we're limited by the behaviour of the underlying OS which isn't directly under our control and doesn't always do what is needed for POSIX semantics because (after all) it was designed to implement win32 semantics. 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 ... Thanks for your explanations. One just has to keep in mind that for every upcoming update of the cygwin1.dll one has to re-run the rebase process. Best regards, Bernd. -- 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: 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_DOS_PATHS define code path in gmake. Personally, I always recompile gmake in cygwin with HAVE_DOS_PATHS defined. Thanks, -Edward -- 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
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 actual execution gives cygwin perl in /bin $ for i in $(echo $PATH | sed -r -e s/:/ /g); do echo $i; done /opt/site/bin /opt/ms-vs-10.0/VC/bin /opt/perl/bin /usr/local/bin /bin /usr/bin ... $ which perl /opt/perl/bin/perl But $ perl --version This is perl, v5.10.1 (*) built for i686-cygwin-thread-muli-64int (with 12 registered patches, see perl -V for more detail) ... If I switch to bash 3.x in /bin things work as expected. $ /bin/bash $ which perl /opt/perl/bin/perl $ perl --version This is perl, v5.10.1 built for MSWin32-x86-multi-thread ... How can I fix bash 4.0 path problems? Regards, Neil -- 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: git stopped working with 1.7.1
On Thu, Dec 24, 2009 at 07:55, Kevin Layer la...@franz.com 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 end hung up unexpectedly fatal: early EOFs: 62% (5708/9205) fatal: index-pack failed I'm no git expert, but that looks to me like the remote side (where the repository is stored) is experiencing the error while it's preparing data for transfer, and your local git is simply reporting the remote error. It also looks like the remote side is actually the same machine but you're using the git:// protocol to access it without specifying a remote server. I've never tried this and would have expected instead to see something like: $ git clone git://localhost/repo/git/acl acl.test or $ git clone some-path/repo/git/acl acl.test I.e. there's something about your command that *I* don't understand. It's probably perfectly fine though, and the problem is with me. Are you intending to clone a repository on the same machine but via the git:// protocol? What if you just do this instead: $ git clone some-path/repo/git/acl acl.test Do you get the same error? Since it looks like the remote is on the same machine as your shell, do you have write access to the actual repository? If so, you could run git-fsck on the repository to make sure it's intact. What about other repositories, do they behave the same way, or is your problem restricted to this one? -- David. -- 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: 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: http://cygwin.com/ml/cygwin-cvs/2009-q4/msg00150.html Tonight (yes, unfortunately) it occured to me that the patch isn't quite correct, yet. I haven't much time, what with vacation and all that, but I know what has to be changed. I'll come up with a better solution in the next couple of days. False alarm. The code is already doing the right thing, AFAICS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
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 changes in 1.7. I liked the old behavior better, but had some trouble changing it back. So here's my little hack for this in case anyone else finds it useful. In your home directory, create a file .Xdefaults containing this line: XTerm*vt100.metaSendsEscape: true This effectively sets the Meta Sends Escape menu option for new xterms, causing the Alt key to work again for command line editing. I'd be glad to hear any background information on the key mapping change, or better ways to restore the old behavior. Gary -- 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: 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 helpful to the HAVE_DOS_PATHS define code path in gmake. Personally, I always recompile gmake in cygwin with HAVE_DOS_PATHS defined. 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 -Rob -- 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: 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 change my cygdrive prefix and then do a mount -a, my mounts as shown by the mount command or catting mtab are not updated. I only tried it with the cygdrive prefix, not with other mounts. The cygdrive prefix is explicitely ignored when calling mount -a. The problem is, I'm not sure anymore *why* I did it that way. I added it to my TODO list, at least to figure out the reason... Thanks, Corinna Hi Corinna... Did you figure out the reason? It seems to me that one could change mount points in a disruptive way as easily as one could change the cygdrive prefix. Both would then have a don't do that to a running system requirement...restarting Cygwin would be required for either a disruptive prefix change or disruptive mount change. When you look at it, could you remove the inconsistant posix=0 from mount and mount -m output for the prefix where posix=0 is the default. Thanks, ...Karl _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ -- 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: 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. Using bash 4.0, 'which' says I should get ActiveState perl, but actual execution gives cygwin perl in /bin Are you sure PATH is the same in bash 3 and 4? You only showed the PATH from bash 4. Just out of curiosity, what does perl -e 'print $^X' print in those two situations? Also, try running for i in $(echo $PATH | sed -r -e s/:/ /g); do ls -l $i/perl; done in both shells. -- Life is complex, with real and imaginary parts -- 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: 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 already accepted upstream and exist in the GNU Make trunk baseline. So all that remains is for GNU Make 3.82 to be publicly released, and then updated downstream in cygwin. I think the best we can hope for is to recompile cygwin's make with HAVE_DOS_PATHS defined one day without manual patching. :) Regards, -Edward -- 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
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 2008-11-25 19:45 VCS_INFO_detect_git | -rwxr-x---+ 1 seh Users 2959 2008-11-25 19:45 VCS_INFO_get_data_git | -rwxr-x---+ 1 seh Users 163034 2008-11-25 19:45 _git | -rwxr-x---+ 1 seh Users 2301 2008-11-25 19:45 _stgit | -rwxr-x---+ 1 seh Users144 2008-11-25 19:45 run-help-git ` Is this the right place to report such a problem in more detail, or do I need to contact the git mailing list, or maybe the zsh mailing list? -- Steven E. Harris -- 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
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've tried this same sequence of commands using the shells zsh, bash, and ash, and all fail in the same way. Witness: , | % which unison | unison not found | | % /usr/sbin/alternatives --display unison | unison - status is manual. | link currently points to /usr/bin/unison-2.27 | /usr/bin/unison-2.32 - priority 2032 | /usr/bin/unison-2.27 - priority 2027 | Current `best' version is /usr/bin/unison-2.32. | | % ls -l /usr/bin/unison* | -rwxr-xr-x 1 seh root 1076224 2009-10-01 11:27 /usr/bin/unison-2.27.exe | -rwxr-xr-x 1 seh root 1123840 2009-10-01 11:31 /usr/bin/unison-2.32.exe | lrwxrwxrwx 1 seh None 28 2005-03-24 22:09 /usr/bin/unison.exe - |/etc/alternatives/unison.exe | | torus:~% /usr/bin/unison | zsh: no such file or directory: /usr/bin/unison | | % /usr/bin/unison.exe | zsh: no such file or directory: /usr/bin/unison.exe | | % /etc/alternatives/unison | Usage: unison [options] | or unison root1 root2 [options] | or unison profilename [options] | | For a list of options, type unison -help. | For a tutorial on basic usage, type unison -doc tutorial. | For other documentation, type unison -doc topics. ` I used to just be able to type unison at the command prompt and invoke it like any other program. Is this a permissions problem? I have found that other programs using the alternatives facility work as expected. Why is unison different? [I've tried posting this message with the cygcheck output attached, but the messages get rejected.] -- Steven E. Harris -- 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: 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 program can't be invoked in the normal ways. I've tried this same sequence of commands using the shells zsh, bash, and ash, and all fail in the same way. Witness: , | % which unison | unison not found | | % /usr/sbin/alternatives --display unison | unison - status is manual. | link currently points to /usr/bin/unison-2.27 | /usr/bin/unison-2.32 - priority 2032 | /usr/bin/unison-2.27 - priority 2027 | Current `best' version is /usr/bin/unison-2.32. | | % ls -l /usr/bin/unison* | -rwxr-xr-x 1 seh root 1076224 2009-10-01 11:27 /usr/bin/unison-2.27.exe | -rwxr-xr-x 1 seh root 1123840 2009-10-01 11:31 /usr/bin/unison-2.32.exe | lrwxrwxrwx 1 seh None 28 2005-03-24 22:09 /usr/bin/unison.exe - |/etc/alternatives/unison.exe | | torus:~% /usr/bin/unison | zsh: no such file or directory: /usr/bin/unison | | % /usr/bin/unison.exe | zsh: no such file or directory: /usr/bin/unison.exe | | % /etc/alternatives/unison | Usage: unison [options] | or unison root1 root2 [options] | or unison profilename [options] | | For a list of options, type unison -help. | For a tutorial on basic usage, type unison -doc tutorial. | For other documentation, type unison -doc topics. ` I used to just be able to type unison at the command prompt and invoke it like any other program. Is this a permissions problem? I have found that other programs using the alternatives facility work as expected. Why is unison different? WJFFM. Try looking at your file permissions to see if you can find anything revealing. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
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. To minimize variables, I started by removing Cygwin entirely from this host. I deleted C:\cygwin, removed the old sshd and sshd_server user accounts, and removed those accounts' rights in the Local Security Policy tool. Cygwin was then installed again. I don't think it matters, but I also noticed that all of these hosts are domain members. All of the other (working) hosts opted to use the sshd and sshd_server domain accounts, while the failing host is using local accounts. I'm not sure how Cygwin interacts with Windows when creating accounts, and what would cause it to use domain accounts on some hosts but local accounts on others. I previously tried removing the local accounts and using mkpasswd.exe to load the domain accounts into /etc/passwd. That attempt also failed, but in a completely different manner. ssh-host-config complained that the local SAM didn't recognize the accounts or something like that. I can do so again if that information is wanted. When the client connects, I get this error: # ssh -i id_rsa gor...@exch64.xxx.local Last login: Tue Dec 29 13:17:34 2009 from backup.xxx.local 1 [main] -bash 6832 C:\cygwin\bin\bash.exe: *** fatal error - couldn't dynamically determine load address for 'WSAGetLastError' (handle 0x), Win32 error 126 Connection to exch64.xxx.local closed. Event viewer records an apparent success: The description for Event ID ( 0 ) in Source ( sshd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: sshd: PID 5872: Accepted publickey for gordon from 192.168.99.4 port 49012 ssh2. The output of cygcheck -s -v -r and ssh-host-config are attached. Please let me know if there is any additional information that I can provide to help diagnose and correct the problem. Cygwin Configuration Diagnostics Current System Time: Tue Dec 29 13:22:34 2009 Windows 2003 Server R2 Ver 5.2 Build 3790 Service Pack 2 Running under WOW64 on AMD64 Running in Terminal Service session Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files\Support Tools\ C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\ATI Technologies\ATI Control Panel\ C:\WINDOWS\system32\WindowsPowerShell\v1.0 C:\Program Files\Microsoft\Exchange Server\bin C:\Program Files\Microsoft\Exchange Server\Scripts C:\WINDOWS\sysWOW64 C:\Program Files (x86)\ExchangeMapi\ Output from C:\cygwin\bin\id.exe UID: 11287(gordon) GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'gordon' PWD = '/home/gordon' CYGWIN = 'tty' HOME = '/home/gordon' HOMEPATH = '\Documents and Settings\gordon.XX' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\gordon.XX\Application Data' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'EXCH64' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'EM64T Family 6 Model 15 Stepping 11, GenuineIntel' WINDIR = 'C:\WINDOWS' OLDPWD = '/etc/skel' USERDOMAIN = 'XX' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'gordon' ClusterLog = 'C:\WINDOWS\Cluster\cluster.log' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\gordon.XX' CLIENTNAME = 'herald' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\EXCH' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' USERDNSDOMAIN = 'XX.LOCAL' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Microsoft XPS Document Writer' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0f0b' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' SESSIONNAME = 'RDP-Tcp#10' COMPUTERNAME = 'EXCH64' _ = '/usr/bin/cygcheck.exe' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
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 startxwin. Sorry about that, Chuck, but this was just the latest of a long string of issues involving these scripts. We've been talking about replacing them for a while, and the recent traffic on the list was enough of an impetus to make me finally stop bandaging the scripts and find a better solution. Plus, we gain argument handling and .startxwinrc, something the scripts would likely never do. Like I said, it sounds to me like a good idea; there's just so many issues that can go (and have gone) wrong in these scripts -- PLUS, whose idea was it to have TWO, one .sh and one .bat?!!? Yeeesh. We're well rid of them. Yes, in fact, I think this deserves a gold star. These things have been a pain in the neck for years. 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
