RE: Wish Setup would accept my Perl
Michael Kairys wrote: > I see that quite a discussion has evolved since last I checked this > thread. Likewise. I've gone round and round on the issues of command.exe, Windows Explorer, Cygwin, and Perl. Perl libraries and the various maintenance tools add yet another dimension of complexity. Going through the various combinations and permutations was very confusing and led to much frustration and wasted effort. My solution was to limit myself to Cygwin, Cygwin Perl, Cygwin Perl libraries, and Perl libraries built from source (using Cygwin tools). If I want to light off a Perl script from Windows land, I write a batch file. This approach is the easiest for me to understand, and works reliably. HTH, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Wish Setup would accept my Perl
Michael Kairys wrote: I want to type "perl foo.pl" at the Bash prompt [snip] I suppose I could rewrite my Bash aliases so "foo" equals "/c/Perl/bin/perl foo.pl" The solution is to break your habit of saying "perl foo.pl". If the first line of a text file begins with "#!" and a valid path name to an executable follows it, Cygwin -- like any *ix -- will consider the executable to be the interpreter for that file, and pass the script as the first argument to the interpreter. So, if you put: #!/usr/bin/perl at the top and run it with the command "foo.pl" from a Cygwin Bash prompt, you get Cygwin perl. No need to reference perl explicitly. If you find that you still need ActiveState Perl, you can use Windows Explorer to associate .pl with it. Then if you run foo.pl from a Run box, an Explorer window, or a cmd.exe prompt, you get AS Perl. None of this helps if you want to use AS Perl from Cygwin or vice versa, of course. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RXVT and Bitstream Vera Sans Mono
* Jeff (Thu, 06 Dec 2007 13:04:36 -0800) > I use RXVT because it makes Cygwin accessible to me. Its color and font > support gives me a console window I can *see*, as opposed to the native > Windows console that BASH runs in by default, which I cannot see. Part > of my strategy to increase visibility is to specify a bold font for > -fn/font: and crank up the point size just as large as I can make it > and still have an 80x25 console fit on my screen. > > I probably don't have to tell anyone who uses RXVT that Windows XP > ships with only two usable monospaced fonts: Lucida Console, and > Courier New; I probably also don't have to mention how well a > proportional font (doesn't) work with RXVT. I've been getting by with > Lucida Console-bold, but lately even that has become a little difficult > for me to see. So, I decided to see if I could find a more visible > font. > > I found this useful page at http://www.lowing.org/fonts/ which lists > several monospaced fonts for coders/programmers, with Bitstream Vera > Sans Mono ranked as the best of them. The page provides links, too-- > the Bitstream fonts are available at http://www.gnome.org/fonts/ as > advertised. I then noticed that this font is mentioned in the RXVT > README text, and saw it mentioned in a recent thread on this list as > being the default font in the current Cygwin RXVT. If you like Bitstream fonts then you will like DejaVu fonts - who are based on Bitstream - even more. But beware that your issue might be a issue similar to this: https://bugs.freedesktop.org/show_bug.cgi?id=10693 Thorsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RXVT and Bitstream Vera Sans Mono
On Dec 6, 2007 4:04 PM, Jeff <[EMAIL PROTECTED]> wrote: > Hi, > > I use RXVT because it makes Cygwin accessible to me. Its color and font > support gives me a console window I can *see*, as opposed to the native > Windows console that BASH runs in by default, which I cannot see. Part > of my strategy to increase visibility is to specify a bold font for > -fn/font: and crank up the point size just as large as I can make it > and still have an 80x25 console fit on my screen. > > I probably don't have to tell anyone who uses RXVT that Windows XP > ships with only two usable monospaced fonts: Lucida Console, and > Courier New; I probably also don't have to mention how well a > proportional font (doesn't) work with RXVT. I've been getting by with > Lucida Console-bold, but lately even that has become a little difficult > for me to see. So, I decided to see if I could find a more visible > font. > > I found this useful page at http://www.lowing.org/fonts/ which lists > several monospaced fonts for coders/programmers, with Bitstream Vera > Sans Mono ranked as the best of them. The page provides links, too-- > the Bitstream fonts are available at http://www.gnome.org/fonts/ as > advertised. I then noticed that this font is mentioned in the RXVT > README text, and saw it mentioned in a recent thread on this list as > being the default font in the current Cygwin RXVT. > > After trying a few point sizes, I quickly determined that the largest I > could use and still have an 80x25 console fit on the screen was 24. > However, I got some really strange display anomalies at that point size > (and not at any other within the range of 22-28)-- and they occur in > all variations of the font: normal, bold, and oblique (Italic). I had > characters overlapping and obscuring each other. In joe, the text > editor I use, a line of text extended farther to the right than where > the cursor would land when given a "goto end of line" command. Any > attempt to edit under those circumstances caused characters to > disappear from the screen; it was necessary to move the cursor and > redraw the screen to see what I had there. > > Setting the size to 23 works just great and is better than using Lucida > Console (or the other fonts mentioned on lowing.org, for that matter), > but 24 is significantly larger and would be easier on my eyes. I > thought it would be better to ask here first before contacting > Bitstream; the font seems to work just fine at that point size in MS > Word. > > I'm running the latest Cygwin RXVT (2.7.10, or 20050409-4) in native > mode (I have no use for X11, since I run only console mode apps in > Cygwin) along with the latest cygwin1.dll release on Win XP Pro SP2 > with all the latest updates. I have tried what I am describing and have > had the same results on three different computors, each running at a > different screen resolution and DPI setting-- the notebook on which I > am typing this maxes out (and is set at) 1024x768, and is set for > Normal size (96 DPI). BASH is my shell, and my .Xdefaults file is as > follows: > > *background: #8A > *foreground: #DADA00 > *colorBD: #D0D0D0 > *colorUL: #8CD70F > *font: "Bitstream Vera Sans Mono Bold-23" > *visualBell: True > *loginShell: True > *termName: rxvt-cygwin-native > *saveLines: 300 > *geometry: 80x25 > > It makes no difference whether I just invoke RXVT and let it call BASH > by default (assuming that RXVT does not read the $SHELL environment > variable, which points to BASH), or make it explicit with 'rxvt.exe -e > bash -li'. > > I hope someone (Charles?) can duplicate my results, and then figure out > what's causing it. Please let me know if any other information is > needed to troubleshoot this. My eyes will thank you, and so will I. > > Jeff > The Bitstream Vera fonts were released a long time ago, and AFAIK have been mostly abandoned by Bitstream (at least you won't get any support from them). The successor to them which has had many updates since their release is the DejaVu fonts. I know they have had many releases and fixed a lot of bugs, so that might resolve this problem you are seeing. You can download them here: http://dejavu.sourceforge.net/wiki/index.php/Download -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RXVT and Bitstream Vera Sans Mono
Hi, I use RXVT because it makes Cygwin accessible to me. Its color and font support gives me a console window I can *see*, as opposed to the native Windows console that BASH runs in by default, which I cannot see. Part of my strategy to increase visibility is to specify a bold font for -fn/font: and crank up the point size just as large as I can make it and still have an 80x25 console fit on my screen. I probably don't have to tell anyone who uses RXVT that Windows XP ships with only two usable monospaced fonts: Lucida Console, and Courier New; I probably also don't have to mention how well a proportional font (doesn't) work with RXVT. I've been getting by with Lucida Console-bold, but lately even that has become a little difficult for me to see. So, I decided to see if I could find a more visible font. I found this useful page at http://www.lowing.org/fonts/ which lists several monospaced fonts for coders/programmers, with Bitstream Vera Sans Mono ranked as the best of them. The page provides links, too-- the Bitstream fonts are available at http://www.gnome.org/fonts/ as advertised. I then noticed that this font is mentioned in the RXVT README text, and saw it mentioned in a recent thread on this list as being the default font in the current Cygwin RXVT. After trying a few point sizes, I quickly determined that the largest I could use and still have an 80x25 console fit on the screen was 24. However, I got some really strange display anomalies at that point size (and not at any other within the range of 22-28)-- and they occur in all variations of the font: normal, bold, and oblique (Italic). I had characters overlapping and obscuring each other. In joe, the text editor I use, a line of text extended farther to the right than where the cursor would land when given a "goto end of line" command. Any attempt to edit under those circumstances caused characters to disappear from the screen; it was necessary to move the cursor and redraw the screen to see what I had there. Setting the size to 23 works just great and is better than using Lucida Console (or the other fonts mentioned on lowing.org, for that matter), but 24 is significantly larger and would be easier on my eyes. I thought it would be better to ask here first before contacting Bitstream; the font seems to work just fine at that point size in MS Word. I'm running the latest Cygwin RXVT (2.7.10, or 20050409-4) in native mode (I have no use for X11, since I run only console mode apps in Cygwin) along with the latest cygwin1.dll release on Win XP Pro SP2 with all the latest updates. I have tried what I am describing and have had the same results on three different computors, each running at a different screen resolution and DPI setting-- the notebook on which I am typing this maxes out (and is set at) 1024x768, and is set for Normal size (96 DPI). BASH is my shell, and my .Xdefaults file is as follows: *background: #8A *foreground: #DADA00 *colorBD: #D0D0D0 *colorUL: #8CD70F *font: "Bitstream Vera Sans Mono Bold-23" *visualBell: True *loginShell: True *termName: rxvt-cygwin-native *saveLines: 300 *geometry: 80x25 It makes no difference whether I just invoke RXVT and let it call BASH by default (assuming that RXVT does not read the $SHELL environment variable, which points to BASH), or make it explicit with 'rxvt.exe -e bash -li'. I hope someone (Charles?) can duplicate my results, and then figure out what's causing it. Please let me know if any other information is needed to troubleshoot this. My eyes will thank you, and so will I. Jeff -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygwin/regtool on 64bit windows (vista)
I'm curious what the plans or status is of compatibility efforts between cygwin (32bit) and 64bit Windows (Vista). In particular, I'm interested in getting 'chere' working on 64bit Vista. I notice chere uses 'regtool', which in turn is a 32bit application. Because it's 32bit, when it tries to access the registry is is getting virtualized into the 32bit space, and as such does not allow chere to interact with the 64bit explorer. I see in the regtool source that there are some options for this (-w and -W), but I don't see those options available in the regtool release on my system (version 1.8), which, afaik, is the latest release. Are there plans to release this version of regtool? The last update to it in CVS was 13 months ago. -w and -W are not documented, and regtool does not seem to recognize the options. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Wish Setup would accept my Perl
On Dec 6, 2007 2:23 PM, Michael Kairys <[EMAIL PROTECTED]> wrote: > William Sutton trilug.org> writes: > > > > Having done a bit of this myself, I'm interested into enquiring further > > into your difficulties. Except for win32-specific modules, perl code > > *should* *just work* for either cygwin perl of for ActiveState. Last I > > checked (and it's been about a year), you should be able to get the > > win32-specific modules for cygwin as well, so I'm not sure why you can't > > just invoke the script in your bash shell and have it run. > > Thank you for your encouraging note. I would prefer to maintain only one Perl > installation and would in fact be perfectly happy to dump AS in favor of > Cygwin if I could do so without major pain. You have encouraged me to at least > give it a try. > The major pain will come with file path names. If you are using Windows paths in your scripts, those will not work in cygwin. Really the issue here is that you have become used to doing something that is bad, which is running windows programs in a cygwin shell. Because Perl exists in both places, you have intertwined yourself into a complex situation of not knowing which scripts run in what environment. I don't think there's an easy fix for this. I actually would recommend the opposite... since AS Perl is the native Windows version, I recommend you use that instead of the cygwin version for anything that interacts in a "windows way" (registry, files, services, etc...). For stuff that works only in cygwin, use the cygwin perl. Since you're at home on the command line, you might want to check out "console" http://sourceforge.net/projects/console/ which offers a marginal improvement over the windows command shell. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Wish Setup would accept my Perl
William Sutton trilug.org> writes: > > Having done a bit of this myself, I'm interested into enquiring further > into your difficulties. Except for win32-specific modules, perl code > *should* *just work* for either cygwin perl of for ActiveState. Last I > checked (and it's been about a year), you should be able to get the > win32-specific modules for cygwin as well, so I'm not sure why you can't > just invoke the script in your bash shell and have it run. Thank you for your encouraging note. I would prefer to maintain only one Perl installation and would in fact be perfectly happy to dump AS in favor of Cygwin if I could do so without major pain. You have encouraged me to at least give it a try. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems with PostgreSQL 8
Sorry about the double post. A message that does not appears on the log file: psql: could not connect to server: Connection reset by peer Is the server running locally and accpeting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? cheers! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Wish Setup would accept my Perl
Having done a bit of this myself, I'm interested into enquiring further into your difficulties. Except for win32-specific modules, perl code *should* *just work* for either cygwin perl of for ActiveState. Last I checked (and it's been about a year), you should be able to get the win32-specific modules for cygwin as well, so I'm not sure why you can't just invoke the script in your bash shell and have it run. William Sutton On Thu, 6 Dec 2007, Michael Kairys wrote: DePriest, Jason R. gmail.com> writes: I have ActiveState Perl installed and cygwin perl. ... I have no problems when I use each version in the appropriate environment. Simple scripts can be written that will run in both environments. ... Cygwin handles the pathing so I never have a problem with a cygwin bash prompt trying to call C:\Perl\bin\perl when I just use 'perl'. It checks /usr/bin/perl first. I see that quite a discussion has evolved since last I checked this thread. Thanks to all of you who shared your experience and advice... I'm convinced that using AS Perl with Cygwin as I do is potentially unstable and I should not continue to ignore the issue. However after reading and re- reading all the posts I do not see a clear solution that fits with my usage. I would like to expand on that a bit and ask you to take one more pass at it. I originally got into Perl when I worked at DEC and needed a language in which I could write build scripts for Unix, VMS, and NT. Perl certainly helped me out there. However today I work almost entirely on Windows, except when I occasionally telnet into a Solaris server. Today, my Perl programs fall roughly into three groups: (1) Personal-use automation-glue scripts which never leave my machine and are likely to be Windows-specific (Registry, Clipboard, OLE) (2) Perl/TK programs that I share with my co-workers, again Windows-specific (3) A small number of scripts that I run on Solaris (but may test on Windows). I use Cygwin on Windows out of preference for the Bash shell, the Unix utilities, and the filesystem semantics. To be perfectly honest I use very little of the rest of Cygwin's wonderfully rich environment. I would be okay with maintaining two Perl environments, even if I had to do both PPM and cpan module management. However I want to type "perl foo.pl" at the Bash prompt and have foo.pl Just Work, whether it is written for AS or is generic enough that it could run under either. I just don't see how to make this work. I suppose I could rewrite my Bash aliases so "foo" equals "/c/Perl/bin/perl foo.pl" (it now equals "perl -S foo.pl") but I don't have all my scripts aliased and I'm used to finding them via the path. I could try "porting" all of my scripts that I can from AS to Cygwin but I really don't know what's involved there. I no longer use AS's debugger or their Komodo product since I discovered I could use Eclipse; but my scripts use Windows path semantics everywhere (in groups 1 and 2 anyway) and I'm sure there are other things that would break. (And I rather like the AS documentation :) I would appreciate any further thought you care to give this question, and TIA. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Wish Setup would accept my Perl
DePriest, Jason R. gmail.com> writes: > I have ActiveState Perl installed and cygwin perl. > ... > I have no problems when I use each version in the appropriate environment. > > Simple scripts can be written that will run in both environments. > ... > Cygwin handles the pathing so I never have a problem with a cygwin > bash prompt trying to call C:\Perl\bin\perl when I just use 'perl'. > It checks /usr/bin/perl first. I see that quite a discussion has evolved since last I checked this thread. Thanks to all of you who shared your experience and advice... I'm convinced that using AS Perl with Cygwin as I do is potentially unstable and I should not continue to ignore the issue. However after reading and re- reading all the posts I do not see a clear solution that fits with my usage. I would like to expand on that a bit and ask you to take one more pass at it. I originally got into Perl when I worked at DEC and needed a language in which I could write build scripts for Unix, VMS, and NT. Perl certainly helped me out there. However today I work almost entirely on Windows, except when I occasionally telnet into a Solaris server. Today, my Perl programs fall roughly into three groups: (1) Personal-use automation-glue scripts which never leave my machine and are likely to be Windows-specific (Registry, Clipboard, OLE) (2) Perl/TK programs that I share with my co-workers, again Windows-specific (3) A small number of scripts that I run on Solaris (but may test on Windows). I use Cygwin on Windows out of preference for the Bash shell, the Unix utilities, and the filesystem semantics. To be perfectly honest I use very little of the rest of Cygwin's wonderfully rich environment. I would be okay with maintaining two Perl environments, even if I had to do both PPM and cpan module management. However I want to type "perl foo.pl" at the Bash prompt and have foo.pl Just Work, whether it is written for AS or is generic enough that it could run under either. I just don't see how to make this work. I suppose I could rewrite my Bash aliases so "foo" equals "/c/Perl/bin/perl foo.pl" (it now equals "perl -S foo.pl") but I don't have all my scripts aliased and I'm used to finding them via the path. I could try "porting" all of my scripts that I can from AS to Cygwin but I really don't know what's involved there. I no longer use AS's debugger or their Komodo product since I discovered I could use Eclipse; but my scripts use Windows path semantics everywhere (in groups 1 and 2 anyway) and I'm sure there are other things that would break. (And I rather like the AS documentation :) I would appreciate any further thought you care to give this question, and TIA. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems with PostgreSQL 8
Hello! Before someone tells me to use Linux or a NT based win to run a native Postgres, I must say that I have no choice regarding the use of Postgres on old Win98 machines - this is a huge project that involves some schools that still have this OS and will take a little longer for them to switch to Linux. Given this background information, let me tell my problem: when I try to run the postmaster everything goes fine. But any attempt to connect or run external scripts fails. See below: LOG: could not recognize system timezone, defaulting to "Etc/GMT+3" HINT: You can specify the correct timezone in postgresql.conf. 165 [main] postmaster 712289 child_info::sync: wait failed, pid 901337, Win32 error 0 952 [main] postmaster 712289 fork: child 901337 - died waiting for dll loading, errno 11 LOG: could not fork startup process: Resource temporarily unavailable I need it wirking as soon as possible. so, any help would make me glad! Thanks1 -- http://www.geeknerdnanico.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: [experimental] cygwin-1.5.25-4
On Dec 6 15:37, Dr. Volker Zell wrote: > > Corinna Vinschen writes: > > > I've made another version of the Cygwin DLL, 1.5.25-4, and associated > > utilities available for testing. Version 1.5.24-2 remains the current > > version for now. > > > This is a bug fix release. If nothing serious crops up TODAY or > TOMORROW, > > I intend to make this the new Cygwin version on SATURDAY. > > I just installed 1.5.25-4 and again noticed console windows popping up > and vanish during my fetchmail run against our IMAP server. This happens > everytime a mail gets fetched and delivered to procmail. > > I reported this already in > http://sourceware.org/ml/cygwin/2007-04/msg00156.html > > See also: http://sourceware.org/ml/cygwin/2007-07/msg00549.html This is not a regression from 1.5.24 so I won't stop the release for that. My earlier response is still true, I don't see any change in the ChangeLog which would explain this. Somebody will have to debug this. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: [experimental] cygwin-1.5.25-4
> Corinna Vinschen writes: > I've made another version of the Cygwin DLL, 1.5.25-4, and associated > utilities available for testing. Version 1.5.24-2 remains the current > version for now. > This is a bug fix release. If nothing serious crops up TODAY or TOMORROW, > I intend to make this the new Cygwin version on SATURDAY. I just installed 1.5.25-4 and again noticed console windows popping up and vanish during my fetchmail run against our IMAP server. This happens everytime a mail gets fetched and delivered to procmail. I reported this already in http://sourceware.org/ml/cygwin/2007-04/msg00156.html See also: http://sourceware.org/ml/cygwin/2007-07/msg00549.html My 'fix' was to install snapshot cygwin1-20070330 which didn't show this behavior. I never tested any snapshots since than, my bad :-( Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: unalbe to get a core Dump file
On Dec 6 07:22, Christopher Faylor wrote: > On Thu, Dec 06, 2007 at 12:44:38PM +0100, Corinna Vinschen wrote: > >On Dec 6 12:01, Corinna Vinschen wrote: > >> On Dec 5 23:13, Pedro Alves wrote: > >> > Brian Dessent wrote: > >> > > >> >> As already mentioned downthread, if you want a core dump you should > >> >> simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs > >> >> (which should have all been fixed in the latest version.) > >> > > >> > The cvs version still doesn't work for me if I link > >> > it with the distributed bfd -- it crashes in that case. > >> > The latest fixes were done with a bfd from cvs. > >> > > >> > I haven't tried the latest test version, but > >> > should have the same problem. > >> > >> Do you imply that we need a new binutils package to get dumper working? > > > >I just built dumper with a bfd from CVS HEAD(*). It seems to work on > >the first glance. Setting error_start as above, it catches the division > >by zero from the OP's test app and creates a core file. However, this > >core file doesn't seem to be very helpful, at least when using GDB from > >the distro: > > > >(gdb) i thr > > 3 process 1984 0x7c95077b in ntdll!KiIntSystemCall () > > from /mnt/c/WINDOWS/system32/ntdll.dll > > 2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource () > > from /mnt/c/WINDOWS/system32/ntdll.dll > >* 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource () > > from /mnt/c/WINDOWS/system32/ntdll.dll > > > >None of the backtraces shows anything beyond the system DLLs. > > > >Do we also need a newer GDB for this to be useful? > > I'm not aware of any advances in frame handling in the CVS version of gdb > but I'm waiting for the recent spate of win32 activity to die down before > I release a new version of gdb. That makes sense. A new binutils package might be helpful, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: unalbe to get a core Dump file
On Thu, Dec 06, 2007 at 12:44:38PM +0100, Corinna Vinschen wrote: >On Dec 6 12:01, Corinna Vinschen wrote: >> On Dec 5 23:13, Pedro Alves wrote: >> > Brian Dessent wrote: >> > >> >> As already mentioned downthread, if you want a core dump you should >> >> simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs >> >> (which should have all been fixed in the latest version.) >> > >> > The cvs version still doesn't work for me if I link >> > it with the distributed bfd -- it crashes in that case. >> > The latest fixes were done with a bfd from cvs. >> > >> > I haven't tried the latest test version, but >> > should have the same problem. >> >> Do you imply that we need a new binutils package to get dumper working? > >I just built dumper with a bfd from CVS HEAD(*). It seems to work on >the first glance. Setting error_start as above, it catches the division >by zero from the OP's test app and creates a core file. However, this >core file doesn't seem to be very helpful, at least when using GDB from >the distro: > >(gdb) i thr > 3 process 1984 0x7c95077b in ntdll!KiIntSystemCall () > from /mnt/c/WINDOWS/system32/ntdll.dll > 2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource () > from /mnt/c/WINDOWS/system32/ntdll.dll >* 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource () > from /mnt/c/WINDOWS/system32/ntdll.dll > >None of the backtraces shows anything beyond the system DLLs. > >Do we also need a newer GDB for this to be useful? I'm not aware of any advances in frame handling in the CVS version of gdb but I'm waiting for the recent spate of win32 activity to die down before I release a new version of gdb. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AVG: "Agent.LCA" false positives this morning.
Morning all AVG users out there, There seems to be a false positive in last night's AVG update (pro version, haven't tested the free one yet). It reports Cygwin's tail.exe as being infected with "Trojan horse Agent.LCA". This is happening to us with coreutils-6.7-2. The md5sum of that version of tail.exe is: /bin $ md5sum /bin/tail.exe 8c4f78e8c1ea25079f3098c282ce64b7 */bin/tail.exe I will file a report with Grisoft. Their support department has always been very responsive, so I expect they'll fix it promptly. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: [experimental] cygwin-1.5.25-4
I've made another version of the Cygwin DLL, 1.5.25-4, and associated utilities available for testing. Version 1.5.24-2 remains the current version for now. This is a bug fix release. If nothing serious crops up TODAY or TOMORROW, I intend to make this the new Cygwin version on SATURDAY. Changes since test version 1.5.25-3: - dumper.exe has been linked against the latest BFD code. - Fix a C++ issue with the ftw.h header. Changes since test version 1.5.25-2: - Solve a name clash problem between struct timezone and the timezone variable. - Disallow linking against the old timezone function. Changes since test version 1.5.25-1: - Fix a bug in memory allocation which results in an enormous waste of internal heap memory when using mmap(2) a lot. - Fix a bug in memory allocation which can result in unexpected SEGVs. Important changes since 1.5.24-2: - Always add LOCAL and INTERACTIVE groups to user tokens to fix some permission problems on Windows 2003 Server and later. - Set preferred IO blocksize to 64K for performance reasons. - Add missing baudrates for serial IO up to 3.000.000 baud. - Fix various race conditions in process exit, in dll initialization, when starting native Win32 processes, and in signal handling. - Fix a couple of buffer-related problems when accessing raw disk devices. - Fix bug in dlclose. - Don't set TZ environment variable in calls to tzset. - Don't follow symlinks in calls to open if O_EXCL is given. - Fix deadlock and reentrancy problems in stdio functions. Fix append mode handling in stdio functions. - Fix append mode bug when accessing files > 4 Gigs. - Various fixes to stat/fstat/lstat functions (wrong permission bits, timestamps, etc). - Fix a deadlock problem in fork, as well as a crash on fork after calling shmctl(IPC_RMID). - Add thread-safety to mmap and to XSI IPC calls. - Drop a non-sensical check in pthread_key_create. - Encode special characters in /proc/registry key and value names to avoid invalid character problems. - Assorted fixes to cygpath.exe, cygcheck.exe, dumper.exe and mkgroup.exe. - Various bugfixes to printf/scanf function families. Add support for j, t, and z modifiers to scanf functions. - Close security hole in tmpfile. - Fix potential crashes in argz functions. - Fix long-standing regression in rewind error handling. - Support NULL output buffer in wcstombs. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). You will need to use the 'Exp' radio button to get the test version. If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, 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: [EMAIL PROTECTED] 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. Corinna Vinschen Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: unalbe to get a core Dump file
On Dec 6 12:01, Corinna Vinschen wrote: > On Dec 5 23:13, Pedro Alves wrote: > > Brian Dessent wrote: > > > >> As already mentioned downthread, if you want a core dump you should > >> simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs > >> (which should have all been fixed in the latest version.) > > > > The cvs version still doesn't work for me if I link > > it with the distributed bfd -- it crashes in that case. > > The latest fixes were done with a bfd from cvs. > > > > I haven't tried the latest test version, but > > should have the same problem. > > Do you imply that we need a new binutils package to get dumper working? I just built dumper with a bfd from CVS HEAD(*). It seems to work on the first glance. Setting error_start as above, it catches the division by zero from the OP's test app and creates a core file. However, this core file doesn't seem to be very helpful, at least when using GDB from the distro: (gdb) i thr 3 process 1984 0x7c95077b in ntdll!KiIntSystemCall () from /mnt/c/WINDOWS/system32/ntdll.dll 2 process 3020 0x7c90eb94 in ntdll!LdrAccessResource () from /mnt/c/WINDOWS/system32/ntdll.dll * 1 process 3836 0x7c90eb94 in ntdll!LdrAccessResource () from /mnt/c/WINDOWS/system32/ntdll.dll None of the backtraces shows anything beyond the system DLLs. Do we also need a newer GDB for this to be useful? Corinna (*) Btw., the new testrelease 1.5.24-4 contains this dumper.exe linked against bfd from CVS HEAD. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing on a Samba share drive
On Dec 6 11:16, Albrecht Schlosser wrote: > Christopher Faylor wrote: >> On Wed, Dec 05, 2007 at 11:38:54PM -0500, Larry Hall (Cygwin) wrote: >>> Christopher Faylor wrote: On Wed, Dec 05, 2007 at 10:45:43PM -0500, Larry Hall (Cygwin) wrote: > Tom Leonard wrote: >> Hi, >> I created a Samba share on my Debian system, mapped it to a drive >> letter on my XP Home system and did a full network install of Cygwin >> on the root of the mapped drive. > >>> Has 'setup.exe' finally been updated to create .lnk file style symlinks? >>> Guess it has been a while since I've wandered through that code. :-) >> Ah, good point. I was actually thinking this might have been the same >> thing that as someone on IRC was reporting where I thought they said >> that they just saw .lnk files but I see now that this wasn't mentioned >> above. Sorry about that. >> Same answer, though. Using cygwin utiltities to create the files should >> rectify the problem. > > Well, the OP wrote that he used setup.exe to do "a full network install". > Since setup.exe is a native windows program, would this mean that an > install to a network share wouldn't work? setup.exe is creating symlinks of the "plain file with magic header and system bit set" type, which is also used for unix sockets and also for symlinks if you set the CYGWIN=nowinsymlinks option. The problem with Samba is that it's running on file systems which don't support DOS file attributes natively. However, Samba supports a mapping mechanism which uses the execute bits in the file permissions to simulate the DOS attribute bits system, hidden and archive, as well as, in newer Samba versions, a mapping mechanism which uses extended attributes to map these bits. For more information see `man smb.conf'. Using one of these mechanisms should allow Cygwin symlinks created by setup.exe to work on Samba shares. Of course, they are still just plain files. They are not visible as real symlinks from the Linux side, they still only work from Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: unalbe to get a core Dump file
On Dec 5 23:13, Pedro Alves wrote: > Brian Dessent wrote: > >> As already mentioned downthread, if you want a core dump you should >> simply set error_start=c:/cygwin/bin/dumper.exe, modulo dumper bugs >> (which should have all been fixed in the latest version.) > > The cvs version still doesn't work for me if I link > it with the distributed bfd -- it crashes in that case. > The latest fixes were done with a bfd from cvs. > > I haven't tried the latest test version, but > should have the same problem. Do you imply that we need a new binutils package to get dumper working? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing on a Samba share drive
Christopher Faylor wrote: On Wed, Dec 05, 2007 at 11:38:54PM -0500, Larry Hall (Cygwin) wrote: Christopher Faylor wrote: On Wed, Dec 05, 2007 at 10:45:43PM -0500, Larry Hall (Cygwin) wrote: Tom Leonard wrote: Hi, I created a Samba share on my Debian system, mapped it to a drive letter on my XP Home system and did a full network install of Cygwin on the root of the mapped drive. Has 'setup.exe' finally been updated to create .lnk file style symlinks? Guess it has been a while since I've wandered through that code. :-) Ah, good point. I was actually thinking this might have been the same thing that as someone on IRC was reporting where I thought they said that they just saw .lnk files but I see now that this wasn't mentioned above. Sorry about that. Same answer, though. Using cygwin utiltities to create the files should rectify the problem. Well, the OP wrote that he used setup.exe to do "a full network install". Since setup.exe is a native windows program, would this mean that an install to a network share wouldn't work? Albrecht -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
