Re: [RFC] Packaging texlive
Yaakov (Cygwin/X) writes: tetex is obsolete and needs to be replaced by TeX Live, no question. Jan, I presume you won't mind if we relieve you of this cruft? You presume correctly! In fact, I did done some work on texlive Gub package for Cygwin a couple of years ago https://github.com/janneke/gub/blob/master/gub/specs/cygwin/texlive.py which may or may not help, eg not sure if this https://github.com/janneke/gub/blob/master/patches/texlive-kpathsea-dll.patch is upstream yet. Jan, ping? Thanks Yaakov! Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
Re: [ITP] libiodbc, freetds, mysql, phonon (qt4 deps)
On Tue, 2012-02-28 at 17:43 -0600, Yaakov (Cygwin/X) wrote: * Phonon: ftp://ftp.cygwinports.org/pub/cygwinports/uploads/phonon/ I almost forgot: * automoc4 (build-time dependency of Phonon): ftp://ftp.cygwinports.org/pub/cygwinports/release-2/KDE/automoc4/ Yaakov
HEADSUP: TeX dependency changes
Package maintainers, TeX Live is coming very soon to the distribution. The following packages list a dependency on the old tetex packages, along with their new texlive dependencies as best as I could determine. The setup.hint files on sourceware will be updated accordingly, but please update your local copies, and also let me know ASAP if you have any corrections. logiweb (Klaus Grue): texlive-collection-fontsrecommended texlive-collection-latex texlive-collection-latexrecommended lyx (Bo Peng): texlive-collection-fontsrecommended texlive-collection-fontsextra texlive-collection-htmlxml texlive-collection-latex texlive-collection-latexrecommended texlive-collection-latexextra texlive-collection-pictures texlive-collection-science TeXmacs (Andreas Seidl): texlive-collection-fontsrecommended texlive-collection-latex texlive-collection-latexrecommended Yaakov
Re: [RFC] Packaging texlive
On 2/27/2012 5:51 AM, Yaakov (Cygwin/X) wrote: If you are interested and prepared to take this on, I'd be happy to work with you to make this happen. First I suggest you review the brand-new texlive cygclass and my .cygport files in Ports git: http://cygwin-ports.git.sourceforge.net/ Hi Yaakov, The texlive-collection-* directories in this repository don't have the version of 20110705-texmf_cnf.patch needed for building those packages. It's no problem; I got it by using setup.exe to download the source. But I just thought I should give you a heads-up. Also, I was curious to see how you built asymptote, since I tried it once and failed. But when I try to visit http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/asymptote;a=tree I get 404 - Reading tree failed. Ken
Re: [RFC] Packaging texlive
On Wed, 2012-02-29 at 09:06 -0500, Ken Brown wrote: The texlive-collection-* directories in this repository don't have the version of 20110705-texmf_cnf.patch needed for building those packages. It's no problem; I got it by using setup.exe to download the source. But I just thought I should give you a heads-up. Thanks, I pushed the patch. Also, I was curious to see how you built asymptote, since I tried it once and failed. But when I try to visit http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/asymptote;a=tree I get 404 - Reading tree failed. asymptote was indeed a bit tricky. Everything should be there now. Yaakov
XIO: fatal IO error 108 (Socket operation on non-socket) on X server :0
I have little experience with Cygwin, since I normally do not use Microsoft operating systems; but it is precisely for that reason that I do install cygwin whenever I have to work on a Microsoft system -- for example, when I remove the viruses (Malwarebytes, as per a friend's recommendation) from someone else's Windows XP laptop, which I have been doing for the past couple of days, not because I know anything about Windows, but because I know more than anyone else around here. Anyway, the viruses are all gone now, but it was a fair amount of work, and in order to make the experience even remotely tolerable, I installed Cygwin on this laptop, which is my reward, to myself, for having done this fellow a favor. But I am encountering a curious error. The xinit command creates a root window, but then after a minute, or maybe less, the root window disappears and the command exits with the error message, inter alia, XIO: fatal IO error 108 (Socket operation on non-socket) on X server :0 after 7 requests (7 known processed) with 0 events remaining. winClipboardproc - XOpenDisplay() returned and successfully opened the display waiting for X server to shut down There is more, but you get the idea. Since I almost never use Cygwin, I have little notion of what may be wrong (when I have used Cygwin in the past, I never saw this error message), but if you can diagnose this problem from where you are sitting, or if you can give me a workaround even without diagnosing the problem, please do me the kindness of telling me what to do. I do not normally read this mailing list (an understatement, I never read this mailing list), but you may contact me using any of the means indicated below. Thank you in advance for any and all replies to this inquiry. Jay F. Shachter 6424 N Whipple St Chicago IL 60645-4111 (1-773)7613784 landline (1-410)9964737 GoogleVoice j...@m5.chicago.il.us Quidquid latine dictum sit, altum videtur -- 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/
src/winsup/doc ChangeLog faq-programming.xml f ...
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2012-03-01 01:35:03 Modified files: winsup/doc : ChangeLog faq-programming.xml faq-using.xml Log message: * faq-programming.xml (faq.programming.make-execvp): Remove obsolete information about Tcl/Tk. (faq.programming.dll-relocatable): Ditto. * faq-using.xml (faq.using.tcl-tk): Rewrite to reflect switch to X11 Tcl/Tk. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.386r2=1.387 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-programming.xml.diff?cvsroot=srcr1=1.17r2=1.18 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-using.xml.diff?cvsroot=srcr1=1.43r2=1.44
[PATCH] doc: update tcl/tk FAQ
On Wed, 2012-02-29 at 20:15 -0500, Christopher Faylor wrote: On Wed, Feb 29, 2012 at 06:57:27PM -0600, Yaakov (Cygwin/X) wrote: Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. I agree 100% but this now qualifies as a FAQ so maybe we should add an entry about tcl/tk. Patch attached. Yaakov 2012-02-?? Yaakov Selkowitz yselkowitz@... * faq-programming.xml (faq.programming.make-execvp): Remove obsolete information about Tcl/Tk. (faq.programming.dll-relocatable): Ditto. * faq-using.xml (faq.using.tcl-tk): Rewrite to reflect switch to X11 Tcl/Tk. Index: faq-programming.xml === RCS file: /cvs/src/src/winsup/doc/faq-programming.xml,v retrieving revision 1.17 diff -u -p -r1.17 faq-programming.xml --- faq-programming.xml 13 Aug 2010 11:52:13 - 1.17 +++ faq-programming.xml 1 Mar 2012 05:51:21 - @@ -93,18 +93,6 @@ C:/cygwin/bin /bin ntfs binary,cygexec 0 C:/cygwin/bin /usr/bin ntfs binary,cygexec 0 0 /screen -paraNote that if you have Tcl/Tk installed, you must additionally -exclude literaltclsh84/literal and literalwish84/literal, which -are linked to the Cygwin DLL but are not actually Cygwin programs: -/para - -screen -C:/cygwin/bin/tclsh84.exe /bin/tclsh84.exe ntfs binary,notexec 0 0 -C:/cygwin/bin/tclsh84.exe /usr/bin/tclsh84.exe ntfs binary,notexec 0 0 -C:/cygwin/bin/wish84.exe /bin/wish84.exe ntfs binary,notexec 0 0 -C:/cygwin/bin/wish84.exe /usr/bin/wish84.exe ntfs binary,notexec 0 0 -/screen - paraIf you have added other non-Cygwin programs to a path you want to mount cygexec, you can find them with a script like this: /para @@ -574,8 +562,6 @@ $(LD) EXPFILE --dll -o DLLNAME OBJS LIBS /para paraLIBS is the list of libraries you want to link the DLL against. For example, you may or may not want -lcygwin. You may want -lkernel32. -Tcl links against -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32 --lkernel32. /para paraDEFFILE is the name of your definitions file. A simple DEFFILE would consist of ``EXPORTS'' followed by a list of all symbols which should @@ -614,9 +600,8 @@ int entry (HINSTANT hinst, DWORD reason, } /screen -paraYou may put an optional `--subsystem windows' on the $(LD) lines. The -Tcl build does this, but I admit that I no longer remember whether -this is important. Note that if you specify a --subsytem lt;xgt; flag to ld, +paraYou may put an optional `--subsystem windows' on the $(LD) lines. +Note that if you specify a --subsytem lt;xgt; flag to ld, the -e entry must come after the subsystem flag, since the subsystem flag sets a different default entry point. /para Index: faq-using.xml === RCS file: /cvs/src/src/winsup/doc/faq-using.xml,v retrieving revision 1.43 diff -u -p -r1.43 faq-using.xml --- faq-using.xml 27 Feb 2012 19:45:26 - 1.43 +++ faq-using.xml 1 Mar 2012 05:51:21 - @@ -1060,16 +1060,27 @@ usually all set and you can start the ss /answer/qandaentry qandaentry id=faq.using.tcl-tk -questionparaWhy doesn't Cygwin tcl/tk understand Cygwin paths?/para/question +questionparaWhy do my Tk programs not work anymore?/para/question answer -paraThe versions of Tcl/Tk distributed with Cygwin (e.g. cygtclsh80.exe, -cygwish80.exe) are not actually Cygwin versions of those tools. -They are built as native libraries, which means they do not understand -Cygwin mounts or symbolic links. -/para -paraSee the entry How do I convert between Windows and UNIX paths? -elsewhere in this FAQ. +paraPrevious versions of Tcl/Tk distributed with Cygwin (e.g. tclsh84.exe, +wish84.exe) were not actually Cygwin versions of those tools. +They were built as native libraries, which means they did not understand +Cygwin mounts or symbolic links. This lead to all sorts of problems interacting +with true Cygwin programs./para + +paraAs of February 2012, this was replaced with a version of Tcl/Tk which +uses Cygwin's POSIX APIs and X11 for GUI functionality. If you get a message +such as this when trying to start a Tk app:/para + +screen + Application initialization failed: couldn't connect to display +/screen + +paraThen you need to start an X server, or if one is already running, set the +literalDISPLAY/literal variable to the proper value. The Cygwin distribution +includes an X server; please see the ulink url=http://x.cygwin.com/docs/ug/cygwin-x-ug.html;Cygwin/X User Guide/ulink +for installation and startup instructions. /para/answer/qandaentry qandaentry id=faq.using.ipv6
Re: [PATCH] doc: update tcl/tk FAQ
On Wed, Feb 29, 2012 at 11:56:38PM -0600, Yaakov (Cygwin/X) wrote: On Wed, 2012-02-29 at 20:15 -0500, Christopher Faylor wrote: On Wed, Feb 29, 2012 at 06:57:27PM -0600, Yaakov (Cygwin/X) wrote: Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. I agree 100% but this now qualifies as a FAQ so maybe we should add an entry about tcl/tk. Patch attached. 2012-02-?? Yaakov Selkowitz yselkowitz@... * faq-programming.xml (faq.programming.make-execvp): Remove obsolete information about Tcl/Tk. (faq.programming.dll-relocatable): Ditto. * faq-using.xml (faq.using.tcl-tk): Rewrite to reflect switch to X11 Tcl/Tk. Thanks very much for this, Yaakov. I appreciate that you removed the obsolete stuff as well as adding new wording. Please apply. cgf
Re: [ANNOUNCEMENT] Uploaded base-files-4.1-1
On 28 February 2012 19:58, David Sastre Medina wrote: Version 4.1-1 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.1-1 * Setting a system locale and a per-user locale breaks some configs and doesn't play well with mintty. Changed to a user-defined setting in /etc/profile/lang.* Reported by Peter Rosin and Andy Koppe. See cygwin.com/ml/cygwin/2012-02/msg00448.html Thanks! 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: Recent upgrade to wish leads to a problem
Previously bin/wish was a link to wish84.exe (from memory). Recently it was upgraded to wish 8.5.exe. Now, unless X is also running, wish fails ... I'm not quite certain which recently upgraded package led to this: tcl-tk or tcltk ..? The tcltk libraries now require a running X server in order to display graphics. This is recent and more importantly intentional according to what I've read on this list ... OK, thanks. I'm really miserable about this advance which has messed badly with my preferred MO (amongst other things, not using X). I tried to revert but got into a tangle (and in fact ended up with no wish* under /bin, at all). I have recovered a non-updated Cygwin from about a month ago (i.e. wish - wish84.exe) which of course offers many opportunities for updating packages using setup.exe. It is not clear to me which update opportunity I should decline in order to keep wish - wish84.exe and not move to wish - wish8.5.exe. Searching for this executable under Search packages yielded Search Results Found 1 matches for wish8.5.exe tcl-tk/tcl-tk-8.5.11-1Tcl X11 toolkit so I de-selected this. However, watching the update process unfold, it is clear that *something else* uninstalled tcl-tk (I saw the phrase Uninstalling tcl-tk). Was it expect? python? both of which were selected in the update process. So as before, I have ended up with no wish* under /bin, at all. (Possibly some dependency is missing in setup.ini? Also there appears to be nothing under [prev] under tcl-tk :o( ) I will try to recover the working version from 1 month ago and start again. Q1 It would be good to know what recent update, separate from tcl-tk explicitly listed above, has led to the un-installation of the existing tcl-tk. Any ideas? Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? Thank you. Fergus -- 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: 'more' segment faults with latest cygwin1.dll (1.7.11)
On Feb 28 19:36, Yaakov (Cygwin/X) wrote:
On Tue, 2012-02-28 at 11:24 +0100, Corinna Vinschen wrote:
On Feb 28 03:43, Yaakov (Cygwin/X) wrote:
On Tue, 2012-02-28 at 09:18 +0100, Corinna Vinschen wrote:
It's a bug in more, afaics. In case of pressing 'n', the search
function
is called with a NULL buf argument. However, the function calls
strlen(buf) without checking buf for NULL. The indentation at this
point in the file looks like this `if (strlen(buf) 0) {' has been
added as a kind of patch.
Yes, I had to patch more(1) to use regcomp/regexec instead of
re_comp/re_exec, which we don't have on Cygwin. With your clarification
I should be able to fix it easily.
Just an idea, instead of working around them, why not just add them
to the lib? You could copy the FreeBSD implementation which just
implements them in terms of the regcomp/regexec API:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/lib/libcompat/4.3/re_comp.c?rev=1.1;content-type=text%2Fplain
I thought of that when I first ported util-linux, but these functions
were already marked legacy in SUSv2 and removed from SUSv3, so I wasn't
sure if we wanted to first add now what most libc's already consider
cruft.
If you really think this should be added to Cygwin, I could do it, but I
already have a fix for more(1) so I could do without.
Uh, that wasn't quite what I meant. With lib I meant the lib subdir
in the util-linux source. I was under the (wrong?) impression that the
result of `make' in the lib subdir creates a helper lib which is linked
to all executables in the collection. Alternatively you could have
pasted them to the end of more.c, but since you have a fix now, it
doesn't matter anyway.
As for Cygwin, the aforementioned FreeBSD source builds out of the box
as part of Cygwin after you defined __DECONST. But, like you, I'm not
sure it's such a terrible good idea to add such a long deprecated set of
functions. OTOH, Linux provides them as well, just with the extra kick
that you have to include regex.h rather than unistd.h as on BSD.
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: BLODA detection code in latest snapshot
On Feb 29 02:41, Andrey Repin wrote: Greetings, Corinna Vinschen! Yup, confirmed. This occurs on W7/32 as well. I add shlwapi to the list of filtered DLLs for which no such message is printed. Could you please consider making such list configurable, if it's not much of an issue? This feature seems to be the reasonable way for rough detection of potentially malicious presence, but I would like to avoid certain handlers to be reported, such as antivirus' LSP or keyboard hotkey handler. Hmm. Well, this option isn't meant to be used all the time. It's not overly intrusive, but it costs time and Cygwin already isn't exactly fast. For a pure diagnosing tool, does it makes sense to add lots of configuration options? If you want to make the DLL list configurable, what's your idea? Another env var like, say CYGWIN_DETECT_BLODA_DLL_IGNORE_LIST? 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: Recent upgrade to wish leads to a problem
On Wed, 2012-02-29 at 08:24 +, Fergus wrote: OK, thanks. I'm really miserable about this advance which has messed badly with my preferred MO (amongst other things, not using X). The old 8.4 win32 tcl/tk was unmaintained and broken in many ways, as discussed at length on these lists, and now it is gone and isn't coming back. There is no way to keep the 8.4 version because it would conflict with the 8.5 version now used by everything in the distro, and you can't mix-and-match these. Here's my advice: it would be a better use of your time to install xinit and accustom yourself to the wonders of X rather than hopelessly trying to find a way to continue living in the past. 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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Feb 28 22:41, Corinna Vinschen wrote: The culprit is setup.exe apparently. If it sets 1777 permissions, it uses the same permissions for the inheritable default permissions. It should remove the write bits before creating the inheritable default permissions. In Cygwin this is controlled by the umask, but setup doesn't know about a umask. So, the correct solution is to change setup.exe to create less dangerous default permissions for the Win32 apps in case of 1777 dirs. That makes the tmp/temp stuff in etc/profile unnecessary. I just applied a fix to setup so that the default permissions for dirs created with the sticky bit (t) set don't contain write permissions for group and other. I see to it that it will be uploaded to cygwin.com shortly. The *big* problem are the already existing /tmp dirs with bad permissions throughout the Cygwin users. David, instead of setting tmp/temp, What about adding the following line to /etc/profile? setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2/dev/null That sets the list of directories created with 1777 permissions by setup.exe itself to more sane permissions. Maybe it could be combined with a marker file, along these lines: if [ ! -f /etc/.177fix ] then setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2 /dev/null touch /etc/.177fix fi That should have been /etc/.1777fix, of course. I think something like this is necessary since it makes sure that setfacl is called once by a user with the right permissions and then it's just ignored ever after. 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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Feb 29 02:51, Andrey Repin wrote: Greetings, Corinna Vinschen! Dead on, thanks! The definitions of tmp and temp in /etc/profile result in a double definition of the %TMP% and %TEMP% dos variables from the .Net applications POV and it's too dumb to handle that gracefully. So the solution is, either we drop the tmp and temp definitions in /etc/profile, or old .net apps should be started only after calling `unset tmp temp' in bash. Btw., tmp and temp are not preserved this way in tcsh's profile scripts. So I'm wondering why we do it in /etc/profile. Can somebody give me a management summary? I guess that was an attempt to fix something that isn't made things right, but left there for years. I would rather propose to solve it the other way around and use /etc/fstab functionality to mount Cygwin's /tmp to current user's %TEMP% folder. I don't know, how would that work in multi-user environment, though. POSIX tools usually expect that system paths are shared between processes. Consider client-server situations with shared files (sockets, fifos) in /tmp. So, no, this is not a generic solution for Cygwin tools. Any user or admin is free to do that locally, of course. 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: Recent upgrade to wish leads to a problem
Fergus writes: Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? +1 Please! ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- 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: Recent upgrade to wish leads to a problem
On Feb 29 09:41, Henry S. Thompson wrote: Fergus writes: Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? +1 Please! If you manage to do it so that it does in NO way collide with the new release, then there's nothing speaking against it. Just none of the existing maintainers is interested in maintaining it. http://cygwin.com/acronyms/#SHTDI http://cygwin.com/setup.html 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
Rsync stops inmid of synchronisation
Good day, I've successfully used Cygwin and in particular it's RSYNC for many years, for example to sync a Windows XP computer named Sendi to another XP computer named Desti in a local network. Since a few months however rsync is causing me endless trouble. I regularly upgrade to new versions of Cygwin, so I'm up to date with all Cygwin programs. Now I don't know if my network is the problem (it works fine for all other purposes except rsync) or the rsync program (or its configuration). Maybe somebody knows how I could encircle the problem. Here's the details: - Sendi and Desti are connected via a Ethernet cable to a Router - On Desti rsync runs via rsync --daemon - On Sendi the rsync task is started with rsync foldername/ Desti::modulename/ (and module name is configured as described in Cygwin's or rsync's manual) When the rsync tasks start, at first everything runs fine. I see this by following to Desti's rsync log file and Sendi's verbose output, and at the files being synchronisised. Ie the two rsync programs exchange the files which are out of sync -- but unfortunately just up to a certain point. After a number of files have been transmitted -- and this number varies every time I re-start the task (sometimes it's some 1000 files, sometimes less) -- the two rsync programs stop to talk to each other. Sendi's not continuing to send file names anymore. But why? I've increased Sendi's rsync verbose level to maximum but it just stops to print the file names it wants to send to Desti. So I've started Wireshark to see the network traffic, and next to good RSYNC packages there are also some bad ones named Malformed RSYNC packet in Wireshark. For example Sendi's Wireshark log looks like this: [Malformed Packet: RSYNC] Expert Info (Error/Malformed): Malformed Packet (Exception occurred) Message: Malformed Packet (Exception occurred) Severity level: Error Group: Malformed Since I'm no network expert (I can just start Wireshark and watch the many log entries), does anybody of you Cygwin users know what's happening? To sum up the problem: rsync worked well on Sendi Desti, when suddenly a started rsync task just partly works but then stops. And depending on how many times I re-start the task or the computers, I can get smaller or bigger parts of the whole sync task. Usually not the entire however, because it stops long before the end... Thanks for any hints. -Richard -- 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
Ruby win32ole ADODB.Connection module not found
I need Your help...
I can not create an ADODB.Connection with cygwin/ruby.
I can create the connection with native ruby and in a Visual Basic
script.
What is wrong with my CygWin ruby ?
ruby code
#!/usr/bin/ruby
require 'win32ole'
con = WIN32OLE.new('ADODB.Connection')
/ruby code
result
/minimal.rb:5:in `initialize': failed to create WIN32OLE object from
`ADODB.Connection' (WIN32OLERuntimeError)
HRESULT error code:0x8007007e
/result
Versions:
Windows 7 Professional Service Pack 1, 32 bit
$ ruby --version
ruby 1.8.7 (2012-02-08 patchlevel 358) [i386-cygwin]
/Jesper
--
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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
Greetings, Corinna Vinschen! Dead on, thanks! The definitions of tmp and temp in /etc/profile result in a double definition of the %TMP% and %TEMP% dos variables from the .Net applications POV and it's too dumb to handle that gracefully. So the solution is, either we drop the tmp and temp definitions in /etc/profile, or old .net apps should be started only after calling `unset tmp temp' in bash. Btw., tmp and temp are not preserved this way in tcsh's profile scripts. So I'm wondering why we do it in /etc/profile. Can somebody give me a management summary? I guess that was an attempt to fix something that isn't made things right, but left there for years. I would rather propose to solve it the other way around and use /etc/fstab functionality to mount Cygwin's /tmp to current user's %TEMP% folder. I don't know, how would that work in multi-user environment, though. POSIX tools usually expect that system paths are shared between processes. Consider client-server situations with shared files (sockets, fifos) in /tmp. So, no, this is not a generic solution for Cygwin tools. Any user or admin is free to do that locally, of course. %SystemRoot%/Temp then ? -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.02.2012, 16:21 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: BLODA detection code in latest snapshot
Greetings, Corinna Vinschen! Yup, confirmed. This occurs on W7/32 as well. I add shlwapi to the list of filtered DLLs for which no such message is printed. Could you please consider making such list configurable, if it's not much of an issue? This feature seems to be the reasonable way for rough detection of potentially malicious presence, but I would like to avoid certain handlers to be reported, such as antivirus' LSP or keyboard hotkey handler. Hmm. Well, this option isn't meant to be used all the time. It's not overly intrusive, but it costs time and Cygwin already isn't exactly fast. For a pure diagnosing tool, does it makes sense to add lots of configuration options? No, it doesn't. I've asked just in cause :) If you want to make the DLL list configurable, what's your idea? Another env var like, say CYGWIN_DETECT_BLODA_DLL_IGNORE_LIST? Registry key (REG_MULTI_SZ) would be better. Speaking of which (a list of potentially intrusive DLL's) - do you filter by DLL name or it's full path? Because, %SystemRoot%\system32\shlwapi.dll is likely to be harmless. But same name DLL inserted from any other place... -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.02.2012, 16:09 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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Wed, Feb 29, 2012 at 7:22 AM, Andrey Repin wrote: %SystemRoot%/Temp then ? This isn't guaranteed to exist. -- 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
mintty scroll to bottom
What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. I'd like to have it turned on, i.e., scroll to bottom whenever there is new output. Couldn't find anything for mintty and it seems mintty doesn't scroll. Thanks, Michael -- 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 errors after altering Windows command prompt shortcut (???)
On Tue, Feb 28, 2012 at 9:27 PM, Pat Tressel ptres...@myuw.net wrote: Andrey -- Background: Ok, this is really weird... It's even weirder, than you'd think. Hint: reg:HKEY_CURRENT_USER\Console Oh, that. I could *not* remember console. I was thinking terminal or you know, whatever it is that Windows runs its command prompt in or the thing that has the text color properties and the quick edit mode. (Off topic: Huh. So maybe git or msysgit was monkeying around with the color table...maybe using a non-standard color?) The MSYS part of msysgit doesn't muck with registry keys. Maybe something with tksh that it uses does. -- 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: Problem with daylight saving time, off by one hour
Hi there, 175712 by: Frank Farance 175717 by: Corinna Vinschen 175719 by: Frank Farance 175720 by: Corinna Vinschen 175721 by: Frank Farance 175722 by: Corinna Vinschen 175725 by: Earnie Boyd 175728 by: Frank Farance What are the filesystems involved? VFAT anywhere? -- 73, Ged. -- 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: Problem with daylight saving time, off by one hour
On Tue, Feb 28, 2012 at 3:24 PM, Frank Farance wrote: So I don't believe this is a WinSCP problem, AND the problem is demonstrated independent of WinSCP. What is TZ set to in your Cygwin environment? Try the string EST5EDT to see if it helps. -- 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
How to revert to older Cygwin1 dll?
Hi there As mentioned in another thread bash with the new cygwin1.dll version 1.7.11-1 does not work properly when invoke by NT emacs. It did work before, so I would like to revert to an older version of the cygwin1.dll. How can I do this? And is there a way to revert the other packages so that they are compatible with the older cygwin1 all? Many thanks. Any help is appreciated. It is very annoying to have no bash in NTemacs! Leo -- 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: How to revert to older Cygwin1 dll?
[Reformatted--see: http://cygwin.com/acronyms/#PCYMTWLL ] On 2012-02-29 12:52Z, Leo wrote: As mentioned in another thread bash with the new cygwin1.dll version 1.7.11-1 does not work properly when invoke by NT emacs. It did work before, so I would like to revert to an older version of the cygwin1.dll. How can I do this? And is there a way to revert the other packages so that they are compatible with the older cygwin1 all? That's generally not supported. You could try the Cygwin Time Machine (google for it). Alternatively, if Cygwin 1.5 meets your needs: http://www.cygwin.com/win-9x.html (you can install it alongside 1.7), or try MSYS. -- 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: How to revert to older Cygwin1 dll?
Leo leosli...@letterboxes.org was heard to say: It did work before, so I would like to revert to an older version of the cygwin1.dll. How can I do this? And is there a way to revert the other packages so that they are compatible with the older cygwin1 all? Many thanks. Any help is appreciated. It is very annoying to have no bash in NTemacs! Please be aware that by sticking to an older version of the cygwin1 dll you may cut yourself off of any improvements that Cygwin may provide in the future. If the regression that you reported is not caused by a recently introduced bug but by an improvement of Cygwin's innards, it probably won't be fixed or reverted. You should reconsider your choice of NTEmacs over Cygwin Emacs before doing this. I have used both editors in the past, and the only undisputable advantage of NTEmacs is its support of file drag+drop. I've solved that problem by adding an entry to Explorer's Send to menu. NTEmacs also has major drawbacks such as a speed problem with certain file operations which I've documented here: http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=2022catid=37. I've also figured out a way to run both Emacs flavors off a single .emacs file which might help to wean yourself from NTEmacs, see here: http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=2023catid=37. hope this helps Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: How to revert to older Cygwin1 dll?
On 2/29/2012 1:52 PM, Leo wrote: Hi there As mentioned in another thread bash with the new cygwin1.dll version 1.7.11-1 does not work properly when invoke by NT emacs. It did work before, so I would like to revert to an older version of the cygwin1.dll. How can I do this? And is there a way to revert the other packages so that they are compatible with the older cygwin1 all? Many thanks. Any help is appreciated. It is very annoying to have no bash in NTemacs! Leo 1.7.10-1 is available as previous package through cygwin setup.exe. Older than that, it is a problem and really not recommended as other programs will not work if released after 1.7.10-1 (or 1.7.11) Regards 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: slow ssh login on a cygwin machine
Hi ! 02/28/2012 05:50 PM, ext Corinna Vinschen пишет: Oh, and then again... did you install the bash-completion package on the server? It's known to result in such delays sometimes. I never used it myself so I don't know what it's doing. Somebody else might know more here. That would be a surprise, because the main delay (marked by XXX in the attachment to my first e-mail) is happening after public key offer. Anyway, I removed this bash-completion package and nothing changed. By the way: what is the proper way to remove one single package? I marked it as Uninstall and the setup.exe started to reinstall all other packages. Is it really intended behaviour? Cheers, Ilya -- 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: BLODA detection code in latest snapshot
On 29/02/2012 7:22 AM, Andrey Repin wrote: do you filter by DLL name or it's full path? Because, %SystemRoot%\system32\shlwapi.dll is likely to be harmless. But same name DLL inserted from any other place... That would be moving beyond mere BLODA and into malware territory. At that point, just because it's in %SystemRoot% doesn't mean it's safe, either. In fact, we can't really even be sure a well-known dll name in %SystemRoot% is safe if the machine is infected with something. I don't think we're trying to play virus scanner here, so dll name should suffice. $.02 Ryan -- 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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
On Feb 29 07:39, Earnie Boyd wrote: On Wed, Feb 29, 2012 at 7:22 AM, Andrey Repin wrote: %SystemRoot%/Temp then ? This isn't guaranteed to exist. And it wouldn't change anything. It all depends on a safe ACL setting one way or the other. 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: Problem with daylight saving time, off by one hour
On Feb 29 12:49, G.W. Haywood wrote: Hi there, 175712 by: Frank Farance 175717 by: Corinna Vinschen 175719 by: Frank Farance 175720 by: Corinna Vinschen 175721 by: Frank Farance 175722 by: Corinna Vinschen 175725 by: Earnie Boyd 175728 by: Frank Farance What are the filesystems involved? VFAT anywhere? Apart from the CF cards for ny camera, not in my case, no. NTFS-only on Windows and ext4-only on Linux. 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: BLODA detection code in latest snapshot
On 27/02/2012 7:26 AM, Corinna Vinschen wrote: Hi folks, I've just uploaded a new snapshot 2012-02-27 12:04:23 UTC. It contains two code snippets which are supposed to help diagnosing BLODA problems. If you set the environment variable CYGWIN to detect_bloda and then start a Cygwin process (bash or so), then Cygwin will detect two types of anomalies: - Threads injected into the process from an unknown source. Every thread started in a process triggers a message to the DLLs in a process. When the Cygwin DLL gets this message, it tweaks the function pointer of the thread entry point so that it points to a Cygwin function. Usually Cygwin just performs some setup and then starts the original thread function. If CYGWIN=detect_bloda, then the original function address is evaluated and if the address is neither in the Cygwin DLL, nor in the application image, nor in one of a few filtered system DLLs, then Cygwin prints a message like this: Potential BLODA detected! Thread function called outside of Cygwin DLL: C:\foo\bar\baz.dll Of course this is not foolproof. The only filtered system DLLs so far are kernel32.dll, ntdll.dll, mswsock.dll, amd ws2_32.dll. If you playing around with this, and if you find that a core system DLL is reported (like, say, advapi32.dll), then please notify this list, too. - Some BLODAs affect the network. Winsock allows so-called Layered Service Providers (LSP). The socket handle returned by a socket(2) call is not a real socket, but a pseudo handle returned by the LSP. While Cygwin tries to workaround this, it's nevertheless interesting to learn that an LSP is installed. For instance, there's the Bytemobile optimization client on our BLODA list at http://cygwin.com/faq/faq.using.html#faq.using.bloda If this is installed on your machine, and if you have CYGWIN=detect_bloda set, it's existence will be recognized twice when you try to open a socket connection. First it injects a thread into the application, so you'll see something like this: Potential BLODA detected! Thread function called outside of Cygwin DLL: C:\Windows\System32\bmnet.dll And additionally you'll see this: Potential BLODA detected! Layered Socket Service Provider: BMA over MSAFD Tcpip [TCP/IP] Please note that this new CYGWIN=detect_bloda setting is just for diagnosing BLODA problems. It's no swiss army knife to fix the BLODA problems, but it might help to detect the cause for some of them. Of course I'd be interested in your experience with this and in any BLODA message you get by setting CYGWIN=detect_bloda. Would it be a good idea to update the FAQ's bloda entry with this info? Sure, it's probably going to give occasional false positives and/or negatives, but it would definitely catch the obvious cases and give a quick test for claims of bloda-free systems. You'd almost want a new cygcheck -b option that could fork off a process or two with detect_bloda active and capture any output that results. Ryan -- 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: slow ssh login on a cygwin machine
On Feb 29 16:26, Ilya Dogolazky wrote: Hi ! 02/28/2012 05:50 PM, ext Corinna Vinschen пишет: Oh, and then again... did you install the bash-completion package on the server? It's known to result in such delays sometimes. I never used it myself so I don't know what it's doing. Somebody else might know more here. That would be a surprise, because the main delay (marked by XXX in the attachment to my first e-mail) is happening after public key offer. Anyway, I removed this bash-completion package and nothing changed. By the way: what is the proper way to remove one single package? I marked it as Uninstall and the setup.exe started to reinstall all other packages. Is it really intended behaviour? Yes. setup's default setting is update all packages. There's a command line option which allows to change single packages, though. 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: BLODA detection code in latest snapshot
On Feb 29 09:51, Ryan Johnson wrote: On 27/02/2012 7:26 AM, Corinna Vinschen wrote: Hi folks, I've just uploaded a new snapshot 2012-02-27 12:04:23 UTC. It contains two code snippets which are supposed to help diagnosing BLODA problems. If you set the environment variable CYGWIN to detect_bloda and then start a Cygwin process (bash or so), then Cygwin will detect two types of anomalies: [...] Would it be a good idea to update the FAQ's bloda entry with this info? Sure, it's probably going to give occasional false positives and/or negatives, but it would definitely catch the obvious cases and give a quick test for claims of bloda-free systems. You'd almost want a new cygcheck -b option that could fork off a process or two with detect_bloda active and capture any output that results. Of course I will document this at one point. So far I just didn't. I doubt that the cygcheck -b would be useful, though. Just call $ export CYGWIN=detect_bloda some_executable and you get what you want. 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: Problem with daylight saving time, off by one hour
Corinna Vinschen wrote: On Feb 29 12:49, G.W. Haywood wrote: Hi there, 175712 by: Frank Farance 175717 by: Corinna Vinschen 175719 by: Frank Farance 175720 by: Corinna Vinschen 175721 by: Frank Farance 175722 by: Corinna Vinschen 175725 by: Earnie Boyd 175728 by: Frank Farance What are the filesystems involved? VFAT anywhere? Apart from the CF cards for ny camera, not in my case, no. NTFS-only on Windows and ext4-only on Linux. Corinna NTFS on the windows system, ext3 on the Linux system. -FF -- 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: Problem with daylight saving time, off by one hour
Earnie Boyd wrote: On Tue, Feb 28, 2012 at 3:24 PM, Frank Farance wrote: So I don't believe this is a WinSCP problem, AND the problem is demonstrated independent of WinSCP. What is TZ set to in your Cygwin environment? Try the string EST5EDT to see if it helps. -- Earnie -- https://sites.google.com/site/earnieboyd TZ setting is America/New_York on both machines. Already tried setting EST5EDT (and UTC0), all with same problem. -FF -- 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: perl-Tk widget broken again on perl 5.10.1-5
Thrall, Bryan wrote on 2012-02-27: Thrall, Bryan wrote on 2012-01-25: perl-Tk's widget works just fine with perl5.10.1-3 perl-Tk 804.028-3 but if I upgrade to perl 5.10.1-5, widget breaks again[1] with the following errors repeated until the process is killed: Use of uninitialized value $id in hash element at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 39. Use of uninitialized value $id in delete at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 87. perl-Tk 804.029-1 works just fine with perl 5.10.1-3. cygcheck -svr output attached. Thanks. [1] Original report threads here: http://cygwin.com/ml/cygwin/2009-03/msg00800.html http://cygwin.com/ml/cygwin/2009-07/msg00890.html Ping? This problem is fixed with perl5.10.1-5 perl-Tk 804.030-1 Thanks! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: BLODA detection code in latest snapshot
On 29/02/2012 10:01 AM, Corinna Vinschen wrote: On Feb 29 09:51, Ryan Johnson wrote: On 27/02/2012 7:26 AM, Corinna Vinschen wrote: Hi folks, I've just uploaded a new snapshot 2012-02-27 12:04:23 UTC. It contains two code snippets which are supposed to help diagnosing BLODA problems. If you set the environment variable CYGWIN to detect_bloda and then start a Cygwin process (bash or so), then Cygwin will detect two types of anomalies: [...] Would it be a good idea to update the FAQ's bloda entry with this info? Sure, it's probably going to give occasional false positives and/or negatives, but it would definitely catch the obvious cases and give a quick test for claims of bloda-free systems. You'd almost want a new cygcheck -b option that could fork off a process or two with detect_bloda active and capture any output that results. Of course I will document this at one point. So far I just didn't. I doubt that the cygcheck -b would be useful, though. Just call $ export CYGWIN=detect_bloda some_executable and you get what you want. Sure. That's what I'd do also, but we're both familiar with the bloda. I was thinking more of users sending problem reports. Telling them to attach the output of `cygcheck -svrb' would give us useful information even if they don't (yet) know what the bloda is let alone whether they're affected by it. Sort of like how we could ask users having strange problems to check for a second cygwin1.dll in their path... but it's easier to just ask for cygcheck output and check that. As a bonus, it would catch times where someone (*cough* me *cough*) thinks they're bloda free and so doesn't check for it before reporting a problem. Heck, if we really wanted to go whole-hog, we could add an option to check for dlls in $PATH that have base collisions. Once cygcheck supported both those checks, the fork failure error message could even tell users to run cygcheck before reporting a problem. Actually, now that I think about it, we could just make cygwin list any base collisions among dlls used by a failed forkee and point to the FAQ entry on rebaseall. The info is at our fingertips (dll::preferred_base) and in the absence of base collisions we could spawn a process to check for bloda, whose output (if non-empty) is highly likely to be relevant. The latency of a single spawn is nothing compared to ten failed fork attempts, so it wouldn't make cygwin any slower. Between those two checks, an intelligent user could deal with the vast majority of fork failures without ever invoking the mailing list. No change to cygcheck needed at that point. Of course, SHTDI and I won't be able to until the semester ends, but it should be just a few hours' work. Ryan -- 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: FAQ #4.43
On Feb 21 14:24, Michel Bardiaux wrote: You can add to the BLODA list: AVAST! (www.avast.com). But no need to desinstall; just disable permanently the FILESYSTEM and BEHAVIOR realtime shields. The others (web, p2p, mail, IM) do not seem to interfere with cygwin. Thanks, I added that to the FAQ. Corinna Additional info: after rebaseall, I have had absolutely no fork failures at all even with ALL AVAST! shields enabled.
Re: bash under emacs gives cannot set terminal process group
I have the same issue. More information: If you back down cygwin bash to BASH_VERSION='3.2.51(24)-release', the messages about job control no longer appear when bash starts. However I still can't interrupt jobs started with M-x compile or M-x shell-command, so I'm guessing this has something to do with the latest version of cygwin.dll Ken Brown-6 wrote: This is the native Windows build of emacs, not Cygwin's emacs. -- View this message in context: http://old.nabble.com/bash-under-emacs-gives-%22cannot-set-terminal-process-group%22-tp33399261p33415299.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Rsync stops inmid of synchronisation
One thing to check is the disk drives. I have had rsync stop when it reaches corrupted sectors, especially if those sectors corrupt part of the file system. I don't remember anything helpful in the log files, I just noticed that it wasn't finishing. Try running disk diagnostic software and make sure your hardware is good. What kind of hard drives do you have and what OS? If that doesn't show up anything, I would start by synching just one folder. Create a test folder on both computers and add a few files. Make sure your permissions are correct. Make a change in one file and then run rsync. If it finishes and the logs look good, add more to the test folder and see if you can find where it brakes. You can test things like very large files, and folders with a large number of files. If you can't get it to fail, then the issue may be with the data on one of the computers. The problem may also be with the rsync software, but I can't advise well on that end. LMH Richard Ivarson wrote: Good day, I've successfully used Cygwin and in particular it's RSYNC for many years, for example to sync a Windows XP computer named Sendi to another XP computer named Desti in a local network. Since a few months however rsync is causing me endless trouble. I regularly upgrade to new versions of Cygwin, so I'm up to date with all Cygwin programs. Now I don't know if my network is the problem (it works fine for all other purposes except rsync) or the rsync program (or its configuration). Maybe somebody knows how I could encircle the problem. Here's the details: - Sendi and Desti are connected via a Ethernet cable to a Router - On Desti rsync runs via rsync --daemon - On Sendi the rsync task is started with rsync foldername/ Desti::modulename/ (and module name is configured as described in Cygwin's or rsync's manual) When the rsync tasks start, at first everything runs fine. I see this by following to Desti's rsync log file and Sendi's verbose output, and at the files being synchronisised. Ie the two rsync programs exchange the files which are out of sync -- but unfortunately just up to a certain point. After a number of files have been transmitted -- and this number varies every time I re-start the task (sometimes it's some 1000 files, sometimes less) -- the two rsync programs stop to talk to each other. Sendi's not continuing to send file names anymore. But why? I've increased Sendi's rsync verbose level to maximum but it just stops to print the file names it wants to send to Desti. So I've started Wireshark to see the network traffic, and next to good RSYNC packages there are also some bad ones named Malformed RSYNC packet in Wireshark. For example Sendi's Wireshark log looks like this: [Malformed Packet: RSYNC] Expert Info (Error/Malformed): Malformed Packet (Exception occurred) Message: Malformed Packet (Exception occurred) Severity level: Error Group: Malformed Since I'm no network expert (I can just start Wireshark and watch the many log entries), does anybody of you Cygwin users know what's happening? To sum up the problem: rsync worked well on Sendi Desti, when suddenly a started rsync task just partly works but then stops. And depending on how many times I re-start the task or the computers, I can get smaller or bigger parts of the whole sync task. Usually not the entire however, because it stops long before the end... Thanks for any hints. -Richard -- 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
Re: Cygwin errors after altering Windows command prompt shortcut (???)
Greetings, Earnie Boyd! (Off topic: Huh. So maybe git or msysgit was monkeying around with the color table...maybe using a non-standard color?) The MSYS part of msysgit doesn't muck with registry keys. Maybe something with tksh that it uses does. I think it was his own hands. Windows console colors assignment dialogue have a long-standing behavioral issues, that can impact the end result, if you're unaware of them. -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.02.2012, 23: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
Cygserver startup issue
Hi, I am having the same issue as Charles Wilson as discussed here: http://cygwin.com/ml/cygwin/2012-02/msg00089.html Was there any resolution to this issue? Earlier versions of Cygwin 1.7 worked. This is on a Windows Server 2003, 64-bit. -- 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: [PATCH] base-files-4.0.9: Change prompt if running with admin rights
David Sastre Medina wrote: On Mon, Feb 27, 2012 at 06:11:30PM +0100, Christian Franke wrote: This is an updated version of: http://cygwin.com/ml/cygwin/2011-04/msg00020.html Uses the detection method suggested here: http://cygwin.com/ml/cygwin/2011-04/msg00372.html Tested with bash, dash, mksh, posh, and zsh (with symlink /etc/zprofile - profile) on cygwin 1.7.11-1 and Win7 x64. I've revisited this idea several times, with the purpose of adding /usr/sbin to the PATH and coloring the prompt differently (red?) for admins. Makes sense. Please also include the '#' as the very old very well known root prompt. A Cygwin shell run as admin has more *effective* rights than a Windows console run admin. So there should be a be careful sign. I'll see if I can come up with some variation on your patch that does all this. Thanks, Christian -- 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: 1.7.10/1.7.11: .Net programs started from a cygwin console may fail.
Corinna Vinschen wrote: David, instead of setting tmp/temp, What about adding the following line to /etc/profile? setfacl -m d:g::r-x,d:o:r-x /home /tmp /usr/tmp /var/log /var/run /var/tmp 2/dev/null Will that cause problems if I have: $ mount | grep home C:/Documents and Settings on /home type ntfs (binary) $ getfacl /home # file: /home # owner: Administrators # group: Domain Users user::rwx group::--- group:SYSTEM:rwx group:Users:r-x group:Power Users:r-x mask:rwx other:r-x default:user::rwx default:user:Administrators:rwx default:group::--- default:group:SYSTEM:rwx default:group:Users:r-x default:group:Power Users:r-x default:mask:rwx default:other:r-x $ -- 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: Recent upgrade to wish leads to a problem
Christopher Faylor wrote: The only thing that apparently needs addressing is that you read the list and comprehend what's going on. I wish we could address that by making more people do that. :-) Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? In the case of packages that have both a console mode and an X11 mode, perhaps the package could be split into separate packages, as was done with git, git-gui, and gitk? -- 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: Cygserver startup issue
On 2/29/2012 4:19 PM, Robert Krajewski wrote: I am having the same issue as Charles Wilson as discussed here: http://cygwin.com/ml/cygwin/2012-02/msg00089.html Was there any resolution to this issue? Earlier versions of Cygwin 1.7 worked. This is on a Windows Server 2003, 64-bit. I kinda sorta managed to get it working w/ 1.7.11 (Windows Vista, 32bit): 1) rebaseall 2) remove the service entirely: $ cygrunsrv -R cygserver 3) reinstall the server $ cygserver-config 4) manually start the server as Admin (which will fail): That is: $ /usr/sbin/cygserver.exe 5) then, start the server for real $ cygrunsrv -S cygserver Repeat 2--5 for each service. Yes, it's magic. No, I have no idea why it worked. I just did this yesterday, so I haven't rebooted since (during which reboot process, each service would be started automatically, without the preceeding dance). Not sure if it will keep working then or not. Note, BTW, that I do not have any other problems that would ordinarily indicate the need for rebase and related hoops, on that machine. (The cygcheck issue I reported earlier today was on a completely different system, running a different Windows OS). -- Chuck -- 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: cygheap base mismatch detected
On 2/29/2012 8:30 PM, Charles Wilson wrote: I've been running into a strange error lately (that is, I first noticed it for sure on 1.7.10, but it MIGHT have occurred also on 1.7.9. It persists on 1.7.11). cygcheck -- and *only* cygcheck -- is reporting a cygheap base mismatch but only on an XP64 machine: $ cygcheck -cd cygwin 1 [main] cygcheck (3756) C:\cygwin\bin\cygcheck.exe: *** fatal error - cygheap base mismatch detected - 0x61270870/0x2170870. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Cygwin Package Information Package Version cygwin 1.7.11-1 (Note that cygcheck actually *does* complete the requested command, after the error message from (cygwin1.dll/dcrt0.cc?) is printed. However, a full search of C:\ shows no other cygwin1.dll except C:\cygwin\bin. An explicit search of every directory in $PATH also shows no cygwin1.dll except the expected one. Similarly, I *can* run cygcheck -svr -- it just complains before printing the requested info. See attached [slightly redacted]. (Note again, only one cygwin1.dll present). I don't see this behavior on other (XP32) machines on the same network. Any idea what's going on? Could it have something to do with operating under WOW64 (as 32bit cygwin must)? -- Chuck never seen before your problem and I am running W7/64 all the time. $ cygcheck -cd cygwin Cygwin Package Information Package Version cygwin 1.7.11-1 $ uname -a CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin so it could be a XP64 only problem. Have you eventually multiple copy of cygcheck ? 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: Cygwin errors after altering Windows command prompt shortcut (???)
Earnie Boyd sent the following at Wednesday, February 29, 2012 7:49 AM On Tue, Feb 28, 2012 at 9:27 PM, Pat Tressel wrote: It's even weirder, than you'd think. Hint: reg:HKEY_CURRENT_USER\Console The MSYS part of msysgit doesn't muck with registry keys. Maybe something with tksh that it uses does. Since HKEY_CURRENT_USER\Console has subkeys (on my machine) for bash and cmd, perhaps the key is created and maintained by Window's console handling facilities. Seems to me to be more likely than a cygwin shell knowing about and needing the Windows registry. Just a guess. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
RE: [ANNOUNCEMENT] Uploaded base-files-4.1-1
On 28 February 2012 19:58, David Sastre Medina wrote: 4.1-1 * Setting a system locale and a per-user locale breaks some configs and doesn't play well with mintty. Changed to a user-defined setting in /etc/profile/lang.* Reported by Peter Rosin and Andy Koppe. See cygwin.com/ml/cygwin/2012-02/msg00448.html /etc/profile/lang.* = /etc/profile.d/lang.* --- Disclaimer: Statements made herein are not made on behalf of NIAID.
Mostly fixed issue with pathnames from windows, a few cases to go...
In a recent cygwin update (from cygwin-1.7.10-1), the issues that I
reported in the
following link:
http://cygwin.com/ml/cygwin/2012-01/msg00373.html
``Problems with UNC filenames passed to bash when called from a
windows shortcut,''
have been mostly corrected. The issue was the incorrect processing of
some windows
generated pathnames in certain cases. There are still a few cases that need
fixing as of 29 Feb 2012 (cygwin-1.7.11-1).
To recap, I discovered the issue when calling bash via windows XP by selecting
files with the mouse and dropping them on a bash shortcut which called a shell
script, expecting the filenames to be passed to the shell script. This
happened, except some of the filenames the script received were mangled.
The filenames were mangled when the dragged file was on a network share and had
a space in it (e.g. \\fileshare\file name) and a few other cases with
special characters such '()[{}. Previous discussion indicated that the
problem might have been a correct consequence of bash processing the quoted
backslash \\ and the other special pattern matching, and expansion characters
in bash variables before being passed to the shell script.
I have since determined that it is not a bash issue as it affects dragging and
dropping filenames onto any cygwin/gcc compiled executable (bash being one).
This case is easier to explain than the bash case, and does not (or should not)
involve any backslash/expansion issues since bash is not involved.
The following program when compiled under cygwin/gcc experienced the mangling
of some network filenames as evidenced by the filenames failing the stat():
#include stdlib.h
#include stdio.h
#include unistd.h
#include sys/stat.h
int main(int argc, char **argv) {
argc--; argv++;
struct stat mystat;
while (argc 0) {
if (-1 == stat(*argv, mystat)) {
printf(MANGLED: %s\n, *argv);
} else {
printf(OK FILE: %s\n, *argv);
}
argc--; argv++;
}
printf(Press enter...);
getc(stdin);
return 0;
}
The same program compiled with tcc (tiny c) does not have this problem when
network files are dragged and dropped on it.
A few weeks ago (before a recent cygwin update), the following types of
network filenames became mangled (they also have a \\ in in):
1) any filename with a space in it (windows quotes it to \\share\file name
2) any filename with a '()[{} space or not (quoted or unquoted)
After the recent update, most cases have been fixed, however the following
network filenames (with \\ in them) are still mangled:
1) any filename with a ' in it and NO space in it,
e.g. \\share\file'name becomes \\share\filename and stat() fails.
2) any filename with a { in it and NO space in it,
e.g. \\share\file{name becomes \\share\file and stat() fails.
It still seems that some sort of variable expansion a la bash is happening
at the lowest level of parameter assignment to executables, where it should
not happen.
Thanks for fixing most of the issues, as far as I can tell, these are the last
of the cases that need to be fixed.
John Refling
--
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: Recent upgrade to wish leads to a problem
On Wed, 2012-02-29 at 13:43 -0800, Matt Seitz (matseitz) wrote: Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? Asking the same question in a dozen different ways won't change the answer. Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. In the case of packages that have both a console mode and an X11 mode, perhaps the package could be split into separate packages, as was done with git, git-gui, and gitk? Can you provide examples of packages for which this isn't already the case? 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: Recent upgrade to wish leads to a problem
On Wed, Feb 29, 2012 at 06:57:27PM -0600, Yaakov (Cygwin/X) wrote: On Wed, 2012-02-29 at 13:43 -0800, Matt Seitz (matseitz) wrote: Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? Asking the same question in a dozen different ways won't change the answer. Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. I agree 100% but this now qualifies as a FAQ so maybe we should add an entry about tcl/tk. In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. 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: How to revert to older Cygwin1 dll?
On 01/03/2012, at 12:25 AM, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: Leo leosli...@letterboxes.org was heard to say: It did work before, so I would like to revert to an older version of the cygwin1.dll. How can I do this? And is there a way to revert the other packages so that they are compatible with the older cygwin1 all? Many thanks. Any help is appreciated. It is very annoying to have no bash in NTemacs! Please be aware that by sticking to an older version of the cygwin1 dll you may cut yourself off of any improvements that Cygwin may provide in the future. Thanks for your details. Good point. That's what worries me too. If the regression that you reported is not caused by a recently introduced bug but by an improvement of Cygwin's innards, it probably won't be fixed or reverted. As said in the original post, it did work before. So I really don't have a clue what broke it in bash 4/cygwin 1.7.10 You should reconsider your choice of NTEmacs over Cygwin Emacs before doing this. I have used both editors in the past, and the only undisputable advantage of NTEmacs is its support of file drag+drop. Well, drag+drop plus much easier install: For NTemacs I just copy the binaries to a new machine, hv a working GUI emacs straight away and can add the cygwin stuff only when needed, but for a GUI emacs in cygwin i need to install cygwin, X/cygwin, configure X, run an external bash and then kick off emacs - just in order to use a bash inside emacs. Cheers, Leo -- 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: How to revert to older Cygwin1 dll?
Greetings, Leo! Well, drag+drop plus much easier install: For NTemacs I just copy the binaries to a new machine, hv a working GUI emacs straight away and can add the cygwin stuff only when needed, but for a GUI emacs in cygwin i need to install cygwin, X/cygwin, configure X, run an external bash and then kick off emacs - just in order to use a bash inside emacs. You don't need to run external bash... -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.03.2012, 09:43 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: cygheap base mismatch detected
I can agree having some times same error on multiple machines (win7/64) - but always when running perl. 1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error - cygheap base mismatch detected - 0xE158D0 /0xEF58D0. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. I see this error using 1.7.9 (nearly all baselines till 1.7.10) and 1.7.10 1.7.11 not yet tested). I the error occured once - I can reproduce is running simple perl script in bash like the following: perl -e 'print hello\n;' I checked our installation: There is really only one cygwin installation on it. This is the last issue after all for issues we've had. I've hoped this will be solved in 1.7.11 - I read something about increasing heap space (in a 1.7.11 snapshot I think). What we really have is the following - so perhaps cygwin thinks he will file multiple cygwin1.dll files. We are using German Win7/64. Cygwin is installed into c:\Programme\cygwin. In German Win7 c:\Programme is a system link to c:\Program Files - this is by Win7 automatically. Our IT departement create a junction c:\Programme to c:\Program Files using mklink /J c:\Programme c:\Program Files - cause of other older incompatabilities to our old WinXp environment having a real c:\Programme directory. I'm not sure - but perhaps cause of this - cygwin will came into trouble. @Charles: where is your main installation directory of cygwin. I suppose you've not running a German Win7 installation! Is there a way of instrumentation for this error to get even more information? Can anyone give me a hint - what the real problem for this is! Heap corruption? Too small heap? Wrong DLL loaded at wrong base address? best regards. Heiko -- 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: How to revert to older Cygwin1 dll?
but for a GUI emacs in cygwin i need to install cygwin, X/cygwin, configure X, run an external bash and then kick off emacs - just in order to use a bash inside emacs. You don't need to run external bash... And doesn't emacs-nox.exe allow you to have emacs without X? ..mark -- 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 errors after altering Windows command prompt shortcut (???)
Greetings, Buchbinder, Barry (NIH/NIAID) [E]! It's even weirder, than you'd think. Hint: reg:HKEY_CURRENT_USER\Console The MSYS part of msysgit doesn't muck with registry keys. Maybe something with tksh that it uses does. Since HKEY_CURRENT_USER\Console has subkeys (on my machine) for bash and cmd, perhaps the key is created and maintained by Window's console handling facilities. Seems to me to be more likely than a cygwin shell knowing about and needing the Windows registry. These keys created when you mess with console properties of a running application. I don't touch them and I only have one bogus subkey mentioning summary.bat Don't remember, what was that batch, though. I just deleted the subkey for now. -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.03.2012, 10:04 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: Cygwin errors after altering Windows command prompt shortcut (???)
It's even weirder, than you'd think. Hint: reg:HKEY_CURRENT_USER\Console The MSYS part of msysgit doesn't muck with registry keys. Maybe something with tksh that it uses does. Since HKEY_CURRENT_USER\Console has subkeys (on my machine) for bash and cmd, perhaps the key is created and maintained by Window's console handling facilities. Seems to me to be more likely than a cygwin shell knowing about and needing the Windows registry. Just a guess. On my system, HKEY_CURRENT_USER\Console has a Cygwin subkey (and a Git Bash subkey, but I don't use Git Bash). I don't know if that is still in use (given comments re. Cygwin not needing the registry any longer, which I may have misinterpreted), but with the odd behavior, maybe it is still in use. -- Pat -- 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 errors after altering Windows command prompt shortcut (???)
Andrey -- These keys created when you mess with console properties of a running application. I don't touch them and I only have one bogus subkey mentioning summary.bat Don't remember, what was that batch, though. I just deleted the subkey for now. Aha! So those subkeys would likely only be present if one had non-default values... I already backed up HKEY_CURRENT_USER\Console, so maybe I can delete its Cygwin subkey and see if anything changes. (I think Git Bash put its own little self in there -- I see it has a non-standard font. I believe I started it once, said don't need that, and ignored its shortcut taking up space on my desktop since...) -- Pat -- 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: cygheap base mismatch detected
On Thu, Mar 1, 2012 at 6:56 AM, Heiko Elger wrote: I can agree having some times same error on multiple machines (win7/64) - but always when running perl. 1 [main] perl (7796) c:\programme\cygwin\bin\perl.exe: *** fatal error - cygheap base mismatch detected - 0xE158D0 /0xEF58D0. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Hi Heiko, this old message http://cygwin.com/ml/cygwin/2010-03/msg00660.html and 0xE158D0 0xEF58D0. suggest that is a rebase problem. so read usr/share/doc/rebase/README and try rebaseall from the dash shell We are using German Win7/64. on Win7/64 the rebase problem is very common dur tue the additional dll loaded by the system Heiko 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
question on Cygwin's version of make
I've got a C++ tree that is running under Fedora 14, Fedora 16, and Cygwin. Everything works. Tonight, I needed to test something and was on my Windows box, so I did a cut-and-paste operation which gave me a directory of Copy of myStuff. I did a make and it worked, but I am seeing a message about basename: extra operand 'myStuff'. I figured out that the spaces in the MS Copy of myStuff were the problem and was able to rename w/o spaces and move forward. But I would like to ask if anyone knows what in make uses the basename command so I can try to either massage the Makefile to deal with it or throw a more meaningful error (as in your directory has spaces in it and there will be complaints)? I also noticed that if I run make make.out that the message is printed to the terminal and is not in make.out. What am I missing to capture all output in make.out? Thanks in advance, Paul ps: I haven't included all the details of cygcheck as I think the issue is on my end once I have an idea of why basename is being called -- will gladly provide if it helps -- 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: question on Cygwin's version of make
On Thu, Mar 1, 2012 at 8:13 AM, Paul Allen Newell wrote: I've got a C++ tree that is running under Fedora 14, Fedora 16, and Cygwin. Everything works. Tonight, I needed to test something and was on my Windows box, so I did a cut-and-paste operation which gave me a directory of Copy of myStuff. I did a make and it worked, but I am seeing a message about basename: extra operand 'myStuff'. I figured out that the spaces in the MS Copy of myStuff were the problem and was able to rename w/o spaces and move forward. names with spaces are always a problem for a lot of unix/cygwin program, so my suggestion is to rename the directory. Please also note that copypaste will likely mess your file permission But I would like to ask if anyone knows what in make uses the basename command so I can try to either massage the Makefile to deal with it or throw a more meaningful error (as in your directory has spaces in it and there will be complaints)? I also noticed that if I run make make.out that the message is printed to the terminal and is not in make.out. What am I missing to capture all output in make.out? I like this way make 21 |tee make.out 21 redirect the error message to the std output Thanks in advance, Paul ps: I haven't included all the details of cygcheck as I think the issue is on my end once I have an idea of why basename is being called -- will gladly provide if it helps -- -- 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: question on Cygwin's version of make
Marco: Thanks for reply, my comments inline On 2/29/2012 11:23 PM, marco atzeri wrote: names with spaces are always a problem for a lot of unix/cygwin program, so my suggestion is to rename the directory. Please also note that copypaste will likely mess your file permission Yes, I solved the problem by removing spaces. I always create directories and files without spaces. but a cut-and-paste in Windows doesn't respect such. I haven't seen any permissions problems on a cut-and-paste .. the only issue I see is when I port back to Fedora and have a script to get rid of everything being an executable. I am just hoping that I can understand where basename is executed so I can flag the problem. It ain't a show-stopper, but it would be nice to just do a cut-and-paste followed by a make in the new directory which should tell me you got spaces. I also noticed that if I run make make.out that the message is printed to the terminal and is not in make.out. What am I missing to capture all output in make.out? I like this way make21 |tee make.out 21 redirect the error message to the std output Okay ... interesting ... can I beg a bit more of an explanation as I don't understand the difference between and 21 (bash stuff is an an area that I am maybe less than a newbie) Thanks, Paul -- 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: question on Cygwin's version of make
On Thu, Mar 1, 2012 at 8:23 AM, marco atzeri wrote: On Thu, Mar 1, 2012 at 8:13 AM, Paul Allen Newell wrote: (snip) I also noticed that if I run make make.out that the message is printed to the terminal and is not in make.out. What am I missing to capture all output in make.out? I like this way make 21 |tee make.out 21 redirect the error message to the std output Shouldn't that be make 21 | tee make.out (that's what I use with bash) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: question on Cygwin's version of make
On Thu, Mar 1, 2012 at 8:47 AM, Csaba Raduly wrote: On Thu, Mar 1, 2012 at 8:23 AM, marco atzeri wrote: On Thu, Mar 1, 2012 at 8:13 AM, Paul Allen Newell wrote: (snip) I also noticed that if I run make make.out that the message is printed to the terminal and is not in make.out. What am I missing to capture all output in make.out? I like this way make 21 |tee make.out 21 redirect the error message to the std output Shouldn't that be make 21 | tee make.out yes correct, typo from my side Paul, looks on http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/io-redirection.html for further info. Csaba -- 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
