Trying to add an exit confirmation dialog to Cygwin setup.exe, failing
I want setup to ask for confirmation before exiting when alt+f4 is
pressed, like firefox and many other programs do, rather than
immediately exiting and terminating any download/install in progress,
like it currently does.
I spent many of the past 24 hours reading Win32 API documentation (I'm
not a Windows programmer) and the setup.exe source, and finally
determined that as an initial step to make sure I'm catching the
alt+f4 signal, I could add to Window::WindowProc in window.cc the
lines
if((uMsg==WM_SYSCOMMAND)((wParam0xfff0)==SC_CLOSE)) {
MessageBox(NULL,Got alt+f4 signal,Sys command received, MB_OK |
MB_ICONINFORMATION);
return 0;
}
right before the line
return DefWindowProc (WindowHandle, uMsg, wParam, lParam);
This should show a message that alt+f4 was pressed, and then leave
setup running rather than terminate it.
However, it doesn't work. The message isn't displayed, and setup
terminates immediately.
I grepped the source for DefWindowProc and found two other occurrences
of it, in PickView.cc and proppage.cc, and tried intercepting those
too, in case I'm reading the API docs wrong, but that had no effect.
I created a WinMain program from scratch with the simplest possible message loop
while(GetMessage(msg, NULL, 0, 0))
{
TranslateMessage(msg);
DispatchMessage(msg);
}
My function which I registered for lpfnWndProc just intercepts
SC_CLOSE as above and then calls DefWindowProc for everything else. It
works as expected when I press alt+f4: display the message box, and
then leave the program running.
Cygwin setup.exe's message loop is this
while (GetMessage (msg, NULL, 0, 0) != 0
GetMessage (msg, (HWND) NULL, 0, 0) != -1)
{
if (!IsWindow (WindowHandle) || !IsDialogMessage (WindowHandle, msg))
{
TranslateMessage (msg);
DispatchMessage (msg);
}
}
which baffles me. Is the message loop difference causing the problem?
Where's the correct place to intercept SC_CLOSE in Cygwin's setup?
Re: Trying to add an exit confirmation dialog to Cygwin setup.exe, failing
Cygwin setup.exe's message loop is this while (GetMessage (msg, NULL, 0, 0) != 0 GetMessage (msg, (HWND) NULL, 0, 0) != -1) I might not sufficiently understand Win32 messaging, but to me that looks as if it's dropping every other message. Shirley it should be calling GetMessage only once? Andy
Re: Trying to add an exit confirmation dialog to Cygwin setup.exe, failing
Andy Koppe andy.ko...@gmail.com wrote:
Cygwin setup.exe's message loop is this
while (GetMessage (msg, NULL, 0, 0) != 0
GetMessage (msg, (HWND) NULL, 0, 0) != -1)
I might not sufficiently understand Win32 messaging, but to me that
looks as if it's dropping every other message. Shirley it should be
calling GetMessage only once?
That's what I thought too. But that's the current official source
code, and setup.exe works fine with it like that.
I did try replacing that loop by the standard loop used in Win32
tutorials, which as I mentioned in my original post, I'm using
successfully in my test WinMain program:
while(GetMessage(msg, NULL, 0, 0))
{
TranslateMessage(msg);
DispatchMessage(msg);
}
The replacement caused no apparent change in the behaviour of
setup.exe at all; it still works fine. More relevant to my problem, it
still closes when I press alt+f4, unlike my test WinMain program. That
proves that the message loop isn't the problem, so I still have my
original question: Where's the correct place to intercept SC_CLOSE in
setup.exe?
[RFU] mintty-0.3.6-1
MinTTY 0.3.6 is ready for upload. http://mintty.googlecode.com/svn/pkgs/cygwin/0.3.6-1/mintty-0.3.6-1-src.tar.bz2 http://mintty.googlecode.com/svn/pkgs/cygwin/0.3.6-1/mintty-0.3.6-1.tar.bz2 http://mintty.googlecode.com/svn/pkgs/cygwin/0.3.6-1/setup.hint Changes: - Added a man page. Credit to Lee D. Rothstein for providing the initial push on this. - Added command line options for initial window size and position. - Straightened out some inconsistencies in MinTTY-specific keycodes (which are now documented in the man page). - Fixed crash when encountering unknown long command line option. - Fixed mousewheel overreporting - Fixed incorrect encoding of modifier keys on mouse events The full list of issues addresses by this release is here: http://code.google.com/p/mintty/issues/list?can=1q=Milestone%3A0.3.6 Andy
Re: [RFU] mintty-0.3.6-1
Andy Koppe wrote: MinTTY 0.3.6 is ready for upload. Uploaded. -- Chuck
Re: Upgrade broke Openbox
Yaakov (Cygwin/X) wrote: Ouch. Compiled 5 minutes ago with both 1.5 and 1.7 and still getting this behaviour. Yaakov (Cygwin/X) wrote: Any advice for getting openbox back? The openbox package is extremely overdue for an update (distro: 0.99.1, upstream: 3.4.7.2). There is a current version in Ports, but it has dependencies on glib2 and pango that will need to be updated in the distro first. All I can say is to hang on for a little while until we can get all these other packages sorted out. Yaakov Cygwin/X Any update on this point, 0.99.1 is still here ... I think we are some here that will appreciate having this very small (but smart and beautiful) window manager back ! Is there anything I might try to get it start correctly ? Thanks, Arpel. -- View this message in context: http://www.nabble.com/Upgrade-broke-Openbox-tp20487999p22512089.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Upgrade broke Openbox
Yaakov (Cygwin/X) wrote: Ouch. Compiled 5 minutes ago with both 1.5 and 1.7 and still getting this behaviour. Yaakov (Cygwin/X) wrote: Any advice for getting openbox back? The openbox package is extremely overdue for an update (distro: 0.99.1, upstream: 3.4.7.2). There is a current version in Ports, but it has dependencies on glib2 and pango that will need to be updated in the distro first. All I can say is to hang on for a little while until we can get all these other packages sorted out. Yaakov Cygwin/X Any update on this point, 0.99.1 is still here ... I think we are some here that will appreciate having this very small (but smart and beautiful) window manager back ! Is there anything I might try to get it start correctly ? Thanks, Arpel. -- View this message in context: http://www.nabble.com/Upgrade-broke-Openbox-tp20487999p22512103.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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/
setup.exe crashes when removing xorg-server
Hello, After (actually during) my last cygwin update, the installation procedure crashes when setup tries to uninstall xorg-server. I am running on windows XP I have updated to the latest setup.exe (2.573.2.3), and rebooted. I do not see any x-processes in either task manager or windows services. What are my other options other than a complete re-install? (I looked to see if I could manually remove the package, but I did not see any posts on that). I also tried hiding bash.lst.gz, but that did not help. Thanks, Mirko (Sorry for cross-posting. I was not sure which mailing list this topic would fall under) -- 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/
xterm Home/End keycodes
I'm a bit confused about those. They didn't change during the xorg transition, did they? I could have sworn they sent VT220-style ^[[1; and ^[[4; but actually they send PC-style ^[[H and ^[[F. Of course I should have realised this when I changed F1 to F4 to PC-style codes in MinTTY ... D'oh, Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm Home/End keycodes
On Sat, 14 Mar 2009, Andy Koppe wrote: I'm a bit confused about those. They didn't change during the xorg transition, did they? I could have sworn they sent VT220-style ^[[1; and ^[[4; but actually they send PC-style ^[[H and ^[[F. Of course I should have realised this when I changed F1 to F4 to PC-style codes in MinTTY ... PC-style is the upstream default (I don't recall whether cygwin's older package modified the app-defaults files). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm Home/End keycodes
On Sun, 15 Mar 2009, Andy Koppe wrote: 2009/3/15 Thomas Dickey dic...@his.com: I'm a bit confused about those. They didn't change during the xorg transition, did they? I could have sworn they sent VT220-style ^[[1; and ^[[4; but actually they send PC-style ^[[H and ^[[F. Of course I should have realised this when I changed F1 to F4 to PC-style codes in MinTTY ... PC-style is the upstream default (I don't recall whether cygwin's older package modified the app-defaults files). Thanks, I think my confusion actually stemmed from starting with PuTTY code, which sends VT220-style keys when set to Xterm mode. I tend to ignore PuTTY's keyboard options, since they don't really match xterm's options. I note that Debian uses PC-style too. Is this issue fairly settled then, i.e. do most systems use the PC-style keycodes for their xterm terminfo entries? PC-style's the default since a long time ago when the keyboard tables were constructed for the PC keyboards. I implemented the VT220-style editing-keypad as something that could change from that default, but (aside from one of the terminfo's several years ago using VT220), xterm's used the PC-style since I've been working on it in 1996. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Upgrade broke Openbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arpel wrote: Compiled 5 minutes ago with both 1.5 and 1.7 and still getting this behaviour. That version of openbox is ancient, so I'm not entirely surprised. Any update on this point, 0.99.1 is still here ... I think we are some here that will appreciate having this very small (but smart and beautiful) window manager back ! Is there anything I might try to get it start correctly ? Current versions of openbox require glib2 and pango, which are both horribly outdated in the distro. With Cygwin development focus shifting to 1.7, first I need to rebuild X, update those deps (adding any new prereqs along the way), then I can adopt and update openbox. Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm8jpAACgkQpiWmPGlmQSPcQACg3hVvvLLy3XMqeHOCs7ef5KG0 AB8AoIzZNowFCeeXsIR03FYNhcJTn61g =6fqI -END PGP SIGNATURE- -- 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/cygwin ChangeLog gendef
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-03-14 09:14:47 Modified files: winsup/cygwin : ChangeLog gendef Log message: * gendef: Remove STABS directives. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4403r2=1.4404 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/gendef.diff?cvsroot=srcr1=1.30r2=1.31
winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-03-14 18:35:28 Modified files: cygwin : ChangeLog path.cc Log message: * path.cc (warn_msdos): Don't warn about MS-DOS filenames encountered during initialization. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4404r2=1.4405 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/path.cc.diff?cvsroot=uberbaumr1=1.542r2=1.543
winsup/utils ChangeLog ldd.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-03-14 18:40:59 Modified files: utils : ChangeLog ldd.cc Log message: * ldd.cc (longopts): Add --dll option. (get_module_filename): Generalized wrapper function which avoid path length restrictions. (load_dll): Handle special-case of inspecting a DLL. (start_process): Accept an output parameter isdll. Detect when file to start is a DLL and start a wrapper instead. (print_dlls_and_kill_inferior): When dealing with a DLL, avoid printing everything before the DLL itself first appears. (This is not strictly correct and should be fixed eventually) (report): Deal with DLLs. Don't set a breakpoint for DLLs, just let captive ldd process terminate normally. Pass dll info to print_dlls_and_kill_inferior. (main): Handle special-case --dll option by loading the DLL and exiting. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/utils/ChangeLog.diff?cvsroot=uberbaumr1=1.455r2=1.456 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/utils/ldd.cc.diff?cvsroot=uberbaumr1=1.2r2=1.3
Re: errno.h: ESTRPIPE
On Mar 13 17:47, Christopher Faylor wrote: On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote: On Mar 13 10:50, Christopher Faylor wrote: Defining a unique value means that, if we do decide at some point to add functionality which utilizes that errno there will be no need to recompile the application. That's quite a good argument. If you both think it's a good idea to define this new errno, I'm fine with it, too. I was wondering if we should add a conditionalized #include cygwin/errno.h to newlib's errno.h. Then we could add things without littering the file with #ifdef CYGWIN's. Actually I was going to propose the same idea yesterday when I wrote my reply. But then it occured to me that, *if* we add our own errno.h, we would have to make sure that we start with our own errnos at a value way above EOWNERDEAD so that we don't get an errno clash when new errnos are added to newlib. But in this case we raise the size of _sys_errlist with empty slots for no good reason. And the worst case, newlib adds an errno with another value than what's defined in cygwin/errno.h. So, if we add this errno, just stick it to newlib's sys/errno.h as in Yaakovs original patch. If that's ok with you I'll apply Yaakov's patch on Monday. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: errno.h: ESTRPIPE
On Sat, Mar 14, 2009 at 10:25:59AM +0100, Corinna Vinschen wrote: On Mar 13 17:47, Christopher Faylor wrote: On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote: On Mar 13 10:50, Christopher Faylor wrote: Defining a unique value means that, if we do decide at some point to add functionality which utilizes that errno there will be no need to recompile the application. That's quite a good argument. If you both think it's a good idea to define this new errno, I'm fine with it, too. I was wondering if we should add a conditionalized #include cygwin/errno.h to newlib's errno.h. Then we could add things without littering the file with #ifdef CYGWIN's. Actually I was going to propose the same idea yesterday when I wrote my reply. But then it occured to me that, *if* we add our own errno.h, we would have to make sure that we start with our own errnos at a value way above EOWNERDEAD so that we don't get an errno clash when new errnos are added to newlib. But in this case we raise the size of _sys_errlist with empty slots for no good reason. And the worst case, newlib adds an errno with another value than what's defined in cygwin/errno.h. Ah, right. I think I go through the cycle of thinking this is a good idea and then realizing it won't work every year or so. I guess I needed you to complete the cycle. So, if we add this errno, just stick it to newlib's sys/errno.h as in Yaakovs original patch. If that's ok with you I'll apply Yaakov's patch on Monday. No objections. cgf
Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
--- Sab 14/3/09, Dave Korn ha scritto: Da: Dave Korn Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2 A: cygwin@cygwin.com Data: Sabato 14 marzo 2009, 04:04 Angelo Graziosi wrote: Still continuing to test... Marco Atzeri wrote: if I had ./test_program I see the output on the screen but ./test_program test_output leave test_output empty. If I build that tst case with: gfortran-4 test_program.F -o test_program then $ ./test_program.exe SUCCESS $ ./test_program.exe test_output $ cat test_output SUCCESS Hmm, doesn't work here. 1.5 or 1.7? This is 1.7: ad...@ubik /tmp/fortran/hw $ cat hw.F program main WRITE(*,*) 'SUCCESS' end ad...@ubik /tmp/fortran/hw $ gfortran-4 hw.F -o test_program ad...@ubik /tmp/fortran/hw $ ./test_program.exe test_output ad...@ubik /tmp/fortran/hw $ cat test_output it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked before :-( is it possible that Cygwin-1.7 is fooled by the not like-C standard output ? GFORTRAN_STDOUT_UNIT—Unit number for standard output This environment variable can be used to select the unit number preconnected to standard output. This must be a positive integer. The default value is 6. http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gfortran/GFORTRAN_005fSTDOUT_005fUNIT.html#GFORTRAN_005fSTDOUT_005fUNIT cheers, DaveK Regards Marco -- 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 package: gcc4-4.3.2-2
Marco Atzeri wrote: it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked before :-( Odd! It fails for me on both. (You did update gcc-4 on *both* your installations, right?) is it possible that Cygwin-1.7 is fooled by the not like-C standard output ? GFORTRAN_STDOUT_UNIT—Unit number for standard output This environment variable can be used to select the unit number preconnected to standard output. This must be a positive integer. The default value is 6. I'm not sure. From what I've studied so far of libgfortran/io, I think the fortran unit numbers are mapped to, rather than directly equivalent to, unix fds. It might be a libgfortran bug, or it may even not; there could be some interaction in the cygwin dll between DLL unload and stdio shutdown during the exit sequence that fails to flush the stream properly, for example. Still investigating. cheers, DaveK -- 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 package: gcc4-4.3.2-2
--- Sab 14/3/09, Dave Korn ha scritto: Da: Dave Korn Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2 A: Data: Sabato 14 marzo 2009, 07:56 Marco Atzeri wrote: it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked before :-( Odd! It fails for me on both. (You did update gcc-4 on *both* your installations, right?) yes $ uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ cygcheck -c -d |grep fortran gcc4-fortran 4.3.2-2 libgfortran3 4.3.2-2 $cygcheck ./conftest-15.exe .\conftest-15.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cyggfortran-3.dll $ ./conftest-15.exe conftest.out ; cat conftest.out SUCCESS $ uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.7.0(0.206/5/3) 2009-03-11 14:08 i686 Cygwin cygcheck -c -d |grep fortran gcc4-fortran 4.3.2-2 libgfortran3 4.3.2-2 $ cygcheck ./conftest-17.exe C:\cygwin2\pub\programs\fortran\conftest-17.exe C:\cygwin2\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\RPCRT4.dll C:\cygwin2\bin\cyggcc_s-1.dll C:\cygwin2\bin\cyggfortran-3.dll $ ./conftest-17.exe conftest.out ; cat conftest.out So I can reproduce it only on cygwin-1.7. is it possible that Cygwin-1.7 is fooled by the not like-C standard output ? GFORTRAN_STDOUT_UNIT—Unit number for standard output This environment variable can be used to select the unit number preconnected to standard output. This must be a positive integer. The default value is 6. I'm not sure. From what I've studied so far of libgfortran/io, I think the fortran unit numbers are mapped to, rather than directly equivalent to, unix fds. It might be a libgfortran bug, or it may even not; there could be some interaction in the cygwin dll between DLL unload and stdio shutdown during the exit sequence that fails to flush the stream properly, for example. Still investigating. cheers, DaveK Regards Marco -- 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 package: gcc4-4.3.2-2
Dave Korn wrote: 1.5 or 1.7? I do not use 1.7. uname -a CYGWIN_NT-5.1 mypc 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin cygcheck ./test_program.exe .\test_program.exe C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cyggfortran-3.dll -shared is not (surprisingly) the opposite of -static! -static means link your app against static libs, not DLLs. -shared means build your app as a DLL, not an EXE! If you want to link against shared DLLs, you need add no options at all; that's the default for all the languages (except plain C). In this case gfortran-4.3.2-2 works fine on 1.5 and, perhaps, we have another problem on 1.7! Cheers, Angelo. -- 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/
Clearing the Cygwin console
Hello, on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? Thomas Wiedmann -- 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: Starting other Cygwin console from Cygwin console
cygstart bash Thanks - worked. Thomas Wiedmann -- 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: Clearing the Cygwin console
on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? Ctrl+L. Works in all terminals. Andy -- 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: Clearing the Cygwin console
Ctrl+L. Works in all terminals. Great - thanks - worked. Thomas Wiedmann -- 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: under cygwin, zsh cannot run when built against ncurses9-5.7-13
René Berber wrote: Vin Shelton wrote: Charles Wilson wrote: Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: No you didn't, the point was: use gcc3, in other words: mixing libraries built with gcc3 and gcc4 doesn't work. I think my initial post contains this line: The referenced builds used gcc-4, but the same problem occurred using gcc-3. If I'm wrong, or I'm misunderstanding you, I apologize. In any case, I have now supplied the information requested, no? Building with gcc-4 and the old ncurses produces a working zsh, in case that wasn't clear from my earlier emails. - Vin -- 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: Clearing the Cygwin console
Andy Koppe wrote: on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? Ctrl+L. Works in all terminals. In a DOS console, it doesn't clear and reset the scrollback buffer, only the visible field. I use alias cls='cmd /c cls' in those circumstances. cheers, DaveK -- 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: Clearing the Cygwin console
Dave Korn wrote: In a DOS console, it doesn't clear and reset the scrollback buffer, only the visible field. There's also 'clear.exe', although it also does not clear/reset the scrollback buffer. -- Chuck -- 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: Clearing the Cygwin console
* Thomas Wiedmann (Sat, 14 Mar 2009 10:25:21 +0100) on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? With the clear command. clear is part of ncurses and you have to install it if it is not yet installed. 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: Problems installing Cygwin on Windows XP
* cwcarls...@cox.net (Fri, 13 Mar 2009 14:43:53 -0400) Today, I tried to install it on my Windows XP system at work. I downloaded the entire release (Download without Installing) and copied this to a CD. I got the release from kernel.org. I had to do this because we don't have full Internet access at work. It installed Cygwin from the CD without a problem, or so it seemed. No errors during the installation. I told it to Install everything. Crappy. Now you have a bloated system with hundreds or thousands of applications you never heard of and will never use. When I run bash.bat, it claims it can't find cygwin1.dll. I searched all through C:\cygwin and can't find a cygwin1.dll. From where is cygwin1.dll supposed to come? Isn't it part of the normal installation? Sure. C:\cygwin\bin\cygwin1.dll Given that such an integral part of the installation is missing, how do I know if some other important part is missing? Where can I get a cygwin1.dll that corresponds to the release I just downloaded? Read the setup.log and setup.log.full files and then reinstall (after analyzing and fixing the original problem). 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: Clearing the Cygwin console
Andy Koppe wrote: on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? Ctrl+L. Works in all terminals. clear.exe is available in the ncurses package. As Andy said ^-l works. However, with both clear and ^-l, the scroll buffer is not cleared which makes it use with text-based debugging rather limited. That's one reason the alternate screen option on 'rxvt', and 'xterm' is useful. -- 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: Clearing the Cygwin console
Lee D. Rothstein wrote: Andy Koppe wrote: on Linux/UNIX systems with the command 'clear' the console content usually can be flushed, on Windows with 'cls'. None of these commands worked with Cygwin. If I enter 'clear', the message bash: clear: command not found is returned. How can a console used with Cygwin be cleared? Ctrl+L. Works in all terminals. clear.exe is available in the ncurses package. As Andy said ^-l works. However, with both clear and ^-l, the scroll buffer is not cleared which makes it use with text-based debugging rather limited. That's one reason the alternate screen option on 'rxvt', and 'xterm' is useful. For gui consoles, use alias cls='echo -e \033c' which does clear the scrollback buffer. cheers, DaveK -- 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: MinTTY 0.3.3
On Sun, Mar 08, 2009 at 09:37:03PM +, Andy Koppe wrote: What I found missing in Mintty is putty feature to start duplicate session (more welcome with hot-keys) Since MinTTY doesn't have sessions like Putty, I didn't think there was much point in keeping this. It's because you remove networking function from putty, right. IMHO this feature will help many user (especially who come from Windows word) and will give sort of additional point for Mintty (regarding flame war between mintty and rxvt). I don't know the relationship between networking function in Putty with duplicate session feature in code point of view, but since this based on putty code I hope this will not give some sort of difficulty to adopt this feature in mintty. Desktop and quickstart shortcuts already provide quick ways to open a new MinTTY window, and as discussed on a separate thread here you can assign hotkeys to Windows shortcuts. I run Cygwin from portable media in different PC so Desktop and quickstart shortcut not an options in My case. moreover it will replace Mintty lack of tabs problems IMHO. That's not MinTTY's problem, it's Windows'! ;) keep up the good work!! Yup Thanks, Andy -- It is easy to say no when there is a deeper yes burning within -- 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/
Mintty running program from shortcut problem
Dear, When we running program with mintty from shortcut, mintty will running the program in non login shell without knowing cygwin PATH. This will make some kind of error When program try to running external program like info run gzip or using shell escape in vim. Is this expected behavior? Making mintty shortcut running info with this code: code b...@semampir ~ $ mkshortcut -D -i /usr/bin/mintty.exe -w /usr/bin -a info /usr/bin/mintty.exe code When I try to enter the node info produce error like this: gunzip /usr/share/info/as.info.gz.../bin/sh: gunzip: command not found Cannot find node `Top'. note: Making shortcut manually also produce same problem This error not found when using rxvt code b...@semampir ~ $ mkshortcut -D -i /usr/bin/cygicons-0.dll -j8 -w /usr/bin -a -p /usr/bin rxvt -e info /usr/bin/run.exe code To avoid this trouble use bash -lc command so mintty will run bash in login shell first. code b...@semampir ~ $ mkshortcut -D -i /usr/bin/mintty.exe -w /usr/bin -a bash -lc /usr/bin/info /usr/bin/mintty.exe code Regards -- It is easy to say no when there is a deeper yes burning within -- 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: MinTTY 0.3.3
bjoe wrote: It's because you remove networking function from putty, right. IMHO this feature will help many user (especially who come from Windows word) and will give sort of additional point for Mintty (regarding flame war between mintty and rxvt). What flame war? If you like mintty, use it. More power to you. If you like rxvt, use that. Or use both, as the mood strikes you -- that's what I do. That's the point of free software...you're free to use whatever you want. -- Chuck cygwin-rxvt maintainer -- 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: Mintty running program from shortcut problem
When we running program with mintty from shortcut, mintty will running the program in non login shell without knowing cygwin PATH. This will make some kind of error When program try to running external program like info run gzip or using shell escape in vim. Is this expected behavior? Yep. $ mintty --help Usage: ./mintty [OPTION]... [COMMAND [ARGS]...] If no command is given, the user's default shell is invoked as a non-login shell. If the command is a single minus sign, the default shell is invoked as a login shell. Otherwise the command is invoked with the given arguments. ... It's much the same for rxvt (and xterm) btw: without arguments they invoke a non-login shell, and to get a login shell you have to tell them with option -ls. Making mintty shortcut running info with this code: code b...@semampir ~ $ mkshortcut -D -i /usr/bin/mintty.exe -w /usr/bin -a info /usr/bin/mintty.exe code When I try to enter the node info produce error like this: gunzip /usr/share/info/as.info.gz.../bin/sh: gunzip: command not found Cannot find node `Top'. note: Making shortcut manually also produce same problem The problem is that the PATH variable isn't set up, so info can't find gunzip. Invoking a login shell does set up PATH (in /etc/profile), but that's not necessary. This error not found when using rxvt code b...@semampir ~ $ mkshortcut -D -i /usr/bin/cygicons-0.dll -j8 -w /usr/bin -a -p /usr/bin rxvt -e info /usr/bin/run.exe code The difference here is that you're adding /usr/bin to the PATH using the -p option to run.exe. It appears that invoking MinTTY through run.exe keeps its window hidden, which I guess is what run.exe is supposed to do: run - start programs with hidden console window. I don't know why that's different for rxvt. To avoid this trouble use bash -lc command so mintty will run bash in login shell first. code b...@semampir ~ $ mkshortcut -D -i /usr/bin/mintty.exe -w /usr/bin -a bash -lc /usr/bin/info /usr/bin/mintty.exe code As mentioned above, invoking a login shell is overkill here. Just setting PATH will do: $ mkshortcut -D -i /usr/bin/mintty.exe -w /usr/bin -a sh -c 'PATH=/bin info' /usr/bin/mintty.exe Alternatively, you could add C:\cygwin\bin to the Windows Path variable. Andy -- 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/
setup.exe crashes when removing xorg-server
Hello, After (actually during) my last cygwin update, the installation procedure crashes when setup tries to uninstall xorg-server. I am running on windows XP I have updated to the latest setup.exe (2.573.2.3), and rebooted. I do not see any x-processes in either task manager or windows services. What are my other options other than a complete re-install? (I looked to see if I could manually remove the package, but I did not see any posts on that). I also tried hiding bash.lst.gz, but that did not help. Thanks, Mirko (Sorry for cross-posting. I was not sure which mailing list this topic would fall under) -- 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: setup.exe crashes when removing xorg-server
On Sat, 14 Mar 2009, Mirko Vukovic barely.remembered-in.t...@to.munge.this wrote: After (actually during) my last cygwin update, the installation procedure crashes when setup tries to uninstall xorg-server. I am running on windows XP Is the crash something like a window popping up saying that setup.exe has encountered errors and must be terminated? If so: I recently posted a screed when I got hit by that. I have updated to the latest setup.exe (2.573.2.3), and rebooted. I do not see any x-processes in either task manager or windows services. What are my other options other than a complete re-install? (I looked to see if I could manually remove the package, but I did not see any posts on that). I also tried hiding bash.lst.gz, but that did not help. Experts, would it help, or at least not hurt, to hide xorg-server.lst.gz? I would think that hiding bash.lst.gz would help only if it crashed updating bash, not xorg-server. -- Tim McDaniel; Reply-To: t...@panix.com -- 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/
clearing the scrollback buffer in mintty
Dave Korn piped: For gui consoles, use alias cls='echo -e \033c' which does clear the scrollback buffer. Thanks Dave, this works on 'xterm' but not on 'mintty'. On 'mintty' it does a 'clear' (i.e., clears the screen), rather than a 'cls' (i.e., clears the screen and scrollback buffer). -- 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/
Is there a problem with cygport?
---BeginMessage--- A huge number (575) of 'man' pages, that reference other man pages using a '.so' (source include) reference, fail to work because the plain text files have the '.gz' extension appended without actually being gzipped. Could this be due to a mishap in or with the 'cygport' package? Each reference appears to be okay (I've only tested a handful), if you remove the '.gz' extension. Attached is a list of such man page error messages with a few of them actually verified to have the situation I describe above. Lee gzip: /usr/share/man/man1/./reset.1.gz: not in gzip format - Text format: .so tset.1.gz -- valid gzip: /usr/share/man/man3/./addch.3x.gz: not in gzip format - Text format: .so curs_addch.3x.gz -- valid gzip: /usr/share/man/man3/./addchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./assume_default_colors.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attroff.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attron.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attrset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_get.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_off.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_on.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./baudrate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./beep.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgdset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrnd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrndset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bottom_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./can_change_color.3x.gz: not in gzip format gzip: /usr/share/man/man3/./cbreak.3x.gz: not in gzip format gzip: /usr/share/man/man3/./chgat.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clear.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clearok.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtobot.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtoeol.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_content.3x.gz: not in gzip format gzip: /usr/share/man/man3/./COLOR_PAIR.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./copywin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./current_field.3x.gz: not in gzip format - Text format: .so form_page.3x.gz -- valid gzip: /usr/share/man/man3/./current_item.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curses_version.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curs_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_ahead.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_behind.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_prog_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_shell_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delay_output.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./deleteln.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delscreen.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_curterm.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./derwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./doupdate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dupwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dup_field.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dynamic_field_info.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echochar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo_wchar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./endwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erase.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasechar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasewchar.3x.gz: not in gzip format gzip:
[ANNOUNCEMENT] Update: mintty-0.3.6-1
MinTTY is a terminal emulator for Cygwin with a native Windows user interface and minimalist design. Its terminal emulation is largely compatible with xterm, but it does not require an X server to be running. It is based on code from PuTTY 0.60 by Simon Tatham and team. This is a routine update. CHANGES (since 0.3.5-1) === - Added a manual page: 'man mintty'. It documents all the options and keycodes and also has a section with tips on MinTTY usage. Big thanks to Lee D. Rothstein for his help with this. - Added command line options for initial window size and position: --size and --pos. - Straightened out some inconsistencies in MinTTY-specific keycodes (which are now documented in the man page). - Fixed crash when encountering unknown long command line option. - Fixed mousewheel overreporting - Fixed incorrect encoding of modifier keys on mouse events. Details of these changes can be found at http://code.google.com/p/mintty/issues/list?can=1q=Milestone%3A0.3.6 QUESTIONS = MinTTY's project page is located at http://mintty.googlecode.com. Please use the issue tracker there to report bugs or suggest enhancements. Questions or comments can be sent to the MinTTY discussion group at http://groups.google.com/group/mintty-discuss or the Cygwin mailing list at cygwin@cygwin.com . 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. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple -- 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: [1.7] {libXpm-noX/libXpm-noX-devel/libXpm-noX_4}-3.5.7-11
The libXpm-noX packages provide a version of the X.Org XPM image format library that do NOT require the use of an X server. This library can be used to read, process, and save XPM images, but all display code has been removed, because that requires X. It is useful for applications that need to manipulate XPM images, but are not themselves X-based. This is a routine update and feature enhancement. [[ compiled using gcc-3.4.4-999 ]] This is the first release specific for cygwin-1.7; the only differences between this package and the simultaneously-released libXpm-noX-3.5.7-2 for cygwin-1.5 are documentation related (the README references cygport-0.9.5 and cygwin-1.7.0-43, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.x and 0.9.x). CHANGES (since 3.5.6-1) o Fork for cygwin-1.7 development o Updated to latest upstream release o Added libXpm.dll.a, libXpm.a, and libXpm.la compatibility links in /usr/lib/noX/. o Installed sample xpm files o Modified simx.h and simx.c so that function signatures match current Xlib.h and Xutil.h o Added new sxpm-noX.exe program. This is a simple xpm viewer that uses the cygXpm-noX_4.dll. It is used to demonstrate that the noX library is working properly; the display code is WinGDI-based, not X-based. | Usage: sxpm-win [--bgcolor bg] [--zoom sc] [-hv] file.xpm | |-b, --bgcolor=bg desired background color in one of several | formats, or wellknown color names. Formats | include: #rrggbb, #rrrgggbbb, #, | rgb://, MediumPurple4, Gray85, ... | This only matters with transparent images. |-z, --zoom=scdesired scale (must be 1 or larger integer) |-h, --help display this help |-v, --verbosedisplay XPM information | | Press Q, Esc or mouse button 1 (within image window, after image | is displayed) to quit. For example, try: sxpm-noX --zoom 8 --bgcolor darkblue \ /usr/share/doc/libXpm-noX/plaid_mask.xpm -- Charles Wilson volunteer libXpm-noX maintainer for cygwin 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. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: {libXpm-noX/libXpm-noX-devel/libXpm-noX_4}-3.5.7-2
The libXpm-noX packages provide a version of the X.Org XPM image format library that do NOT require the use of an X server. This library can be used to read, process, and save XPM images, but all display code has been removed, because that requires X. It is useful for applications that need to manipulate XPM images, but are not themselves X-based. This is a routine update and feature enhancement. [[ compiled using gcc-3.4.4-999 ]] This will most likely be the final libXpm-noX update for the cygwin-1.5 distribution; future development will continue with libXpm-noX-3.5.7-11 for cygwin-1.7. CHANGES (since 3.5.6-1) o Updated to latest upstream release o Added libXpm.dll.a, libXpm.a, and libXpm.la compatibility links in /usr/lib/noX/. o Installed sample xpm files o Modified simx.h and simx.c so that function signatures match current Xlib.h and Xutil.h o Added new sxpm-noX.exe program. This is a simple xpm viewer that uses the cygXpm-noX_4.dll. It is used to demonstrate that the noX library is working properly; the display code is WinGDI-based, not X-based. | Usage: sxpm-win [--bgcolor bg] [--zoom sc] [-hv] file.xpm | |-b, --bgcolor=bg desired background color in one of several | formats, or wellknown color names. Formats | include: #rrggbb, #rrrgggbbb, #, | rgb://, MediumPurple4, Gray85, ... | This only matters with transparent images. |-z, --zoom=scdesired scale (must be 1 or larger integer) |-h, --help display this help |-v, --verbosedisplay XPM information | | Press Q, Esc or mouse button 1 (within image window, after image | is displayed) to quit. For example, try: sxpm-noX --zoom 8 --bgcolor darkblue \ /usr/share/doc/libXpm-noX-3.5.7/plaid_mask.xpm -- Charles Wilson volunteer libXpm-noX maintainer for cygwin 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. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe crashes when removing xorg-server
On Sat, Mar 14, 2009 at 9:05 PM, t...@panix.com wrote: On Sat, 14 Mar 2009, Mirko Vukovic barely.remembered-in.t...@to.munge.this wrote: After (actually during) my last cygwin update, the installation procedure crashes when setup tries to uninstall xorg-server. I am running on windows XP Is the crash something like a window popping up saying that setup.exe has encountered errors and must be terminated? If so: I recently posted a screed when I got hit by that. Exactly. I should have been more explicit. Now when I restart setup (using `install from local directory'), it crashes once the MD5's have been checke. It crashes when setup tries to uninstall xorg-server. This is the first package that is being uninstalled. I then get two types of crashes - I have not been able to figure out under what circumstances one or the other type happens. In one, a window `MS Visual C++ Runtime Library' `Runtime Error' to the effect taht setup.exe has requested Runtime to terminate it ina an unusual way. In another, I get `setup.exe has encountered a problem and needs to close ...' But see below for good news I have updated to the latest setup.exe (2.573.2.3), and rebooted. I do not see any x-processes in either task manager or windows services. What are my other options other than a complete re-install? (I looked to see if I could manually remove the package, but I did not see any posts on that). I also tried hiding bash.lst.gz, but that did not help. Experts, would it help, or at least not hurt, to hide xorg-server.lst.gz? I would think that hiding bash.lst.gz would help only if it crashed updating bash, not xorg-server. Your comment made me look at xorg-server.lst.gz. That file was probably corrupt (zless could not read it). Once I removed xorg-server.lst.gz, I was able to complete the installation. Thanks Mirko -- 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] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: GNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. This is a bugfix and feature enhancement update. With this release I'm getting the following error with automake 1.9: autoreconf-2.63: running: aclocal --force aclocal: macro `_LT_PREPARE_SED_QUOTE_VARS' required but not defined aclocal: macro `_LT_PROG_ECHO_BACKSLASH' required but not defined autoreconf-2.63: aclocal failed with exit status: 1 If I force automake to 1.9 or 1.10, aclocal works. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkm8ipUACgkQpiWmPGlmQSMI1wCg13Yj+dk4lXRrH2wctVuNA6Gn /5UAoJ3GKwwtRIVHHE3EaclEloeDgIe+ =5ydr -END PGP SIGNATURE- -- 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: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Sat, 14 Mar 2009, Dave Korn wrote: Vin Shelton wrote: How can I ascertain what entry point is not being found? You need depends.exe. http://www.dependencywalker.com/ Thanks, Dave! That's a kool tool! cheers, DaveK -- Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
long unsigned int vs. uint32_t again
Why does the following give me a warning (with -Wformat=2): uint32_t seconds = ... uint32_t minutes = ... uint32_t hours = ... snprintf(buf, sizeof(buf), % PRIu32 :%02 PRIu32 :%02 PRIu32, hours, minutes, seconds); warning: long unsigned int format, uint32_t arg (arg 4) warning: long unsigned int format, uint32_t arg (arg 5) warning: long unsigned int format, uint32_t arg (arg 6) If you've got a uint32_t, then 'PRIu32' is the correct code to use, right? What OTHER code could there be for printing unsigned, 32bit, integers? cygwin's inttypes.h has: #define PRIu8 u #define PRIu16 u #define PRIu32 lu #define PRIu64 llu and stdint.h has typedef unsigned int uint32_t; This is on cygwin-1.7.0-43, with gcc-3.4.4-999. Is it possible that our inttypes.h should be changed, to use u for 8, 16, and 32 bits? Or is gcc's -Wformat=2 in 3.4.4 just too strict here -- and should be checking the actual bitwidths of types against the formats, before assuming that lu doesn't match uint32_t? -- Chuck -- 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: under cygwin, zsh cannot run when built against ncurses9-5.7-13
On Sat, 14 Mar 2009, Vin Shelton wrote: Greetings, All, As the zsh maintainer I guess I get to try and figure out what's going on. :-) Using the Dependency Walker tool that Chuck pointed out (thanks Chuck!), I've found some rather interesting things. The offending symbol entries are the following (functions) tgetent tgetflag tgetnum tgetstr tgoto tputs pow (but this is not an unresolve symbol, see below) 'pow' is not an unresolve symbol in this mess, but it is lumped into the chunk with the bad symbols. libzsh-4.3.9.dll is the one who needs these symbols, but the import list is wrong: Here's the imports from compiling/linking with libncurses-8 (good): 0009e03c 0009e398 0009f37c 0009e6d4 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name Bound-To 9f0181285 pow 0009e050 0009e3a0 0009f3a4 0009e6dc DLL Name: cygncurses-8.dll vma: Hint/Ord Member-Name Bound-To 9f020 405 tgetent 9f02c 406 tgetflag 9f038 407 tgetnum 9f044 408 tgetstr 9f050 409 tgoto 9f058 417 tputs And, here's the imports from compiling/linking with libncurses-9 (bad): 0009e03c 0009e398 0009f374 0009e6d0 DLL Name: cygwin1.dll vma: Hint/Ord Member-Name Bound-To 9f0101285 pow 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs 0009e050 0009e39c 0009f39c 0009e6d4 DLL Name: cygncurses-9.dll vma: Hint/Ord Member-Name Bound-To 9f018 468 tgetent 9f024 469 tgetflag 9f030 470 tgetnum 9f03c 471 tgetstr 9f048 472 tgoto 9f050 480 tputs It appears to trying to import the symbols twice. I've checked the import libs for both 5.5-3 (good) 5.7-13 (bad) and they don't appear to have anything funny about them. libncurses.a and libncurses.dll.a both appear to have the correct exports. There's no difference in how zsh is compiled between ncurses 8 9. Could this really be a linker problem? My build was done using gcc3, and Vin stated he'd tested with both gcc3 and gcc4, so perhaps there's a common element between them? Or, perhaps, is something not quite right with libncurses9 ? I'm a but stuck now as I'm not sure where to look next. Any educated guesses to point me in the right direction? Anyone? Anyone? Bueller? René Berber wrote: Vin Shelton wrote: Charles Wilson wrote: Just for grins, could you rebuild zsh against libncurses9 -- but this time use gcc3? cygiconv-2 and cygncurses-9 use the static gcc-3.4.4 libgcc.a, but you are apparently using the gcc-4.3.2 shared libgcc. I just wonder if that presents an incompatibility that could explain what you are seeing. Thanks for replying, Chuck. As I mentioned in the initial email, I had already done just that. Just to be sure, I did it again, with the same result: No you didn't, the point was: use gcc3, in other words: mixing libraries built with gcc3 and gcc4 doesn't work. I think my initial post contains this line: The referenced builds used gcc-4, but the same problem occurred using gcc-3. If I'm wrong, or I'm misunderstanding you, I apologize. In any case, I have now supplied the information requested, no? Building with gcc-4 and the old ncurses produces a working zsh, in case that wasn't clear from my earlier emails. - Vin -- 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/ -- Peter A. Castro doc...@fruitbat.org or peter.cas...@oracle.com Cats are just autistic Dogs -- Dr. Tony Attwood -- 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/
Updated: {libXpm-noX/libXpm-noX-devel/libXpm-noX_4}-3.5.7-2
The libXpm-noX packages provide a version of the X.Org XPM image format library that do NOT require the use of an X server. This library can be used to read, process, and save XPM images, but all display code has been removed, because that requires X. It is useful for applications that need to manipulate XPM images, but are not themselves X-based. This is a routine update and feature enhancement. [[ compiled using gcc-3.4.4-999 ]] This will most likely be the final libXpm-noX update for the cygwin-1.5 distribution; future development will continue with libXpm-noX-3.5.7-11 for cygwin-1.7. CHANGES (since 3.5.6-1) o Updated to latest upstream release o Added libXpm.dll.a, libXpm.a, and libXpm.la compatibility links in /usr/lib/noX/. o Installed sample xpm files o Modified simx.h and simx.c so that function signatures match current Xlib.h and Xutil.h o Added new sxpm-noX.exe program. This is a simple xpm viewer that uses the cygXpm-noX_4.dll. It is used to demonstrate that the noX library is working properly; the display code is WinGDI-based, not X-based. | Usage: sxpm-win [--bgcolor bg] [--zoom sc] [-hv] file.xpm | |-b, --bgcolor=bg desired background color in one of several | formats, or wellknown color names. Formats | include: #rrggbb, #rrrgggbbb, #, | rgb://, MediumPurple4, Gray85, ... | This only matters with transparent images. |-z, --zoom=scdesired scale (must be 1 or larger integer) |-h, --help display this help |-v, --verbosedisplay XPM information | | Press Q, Esc or mouse button 1 (within image window, after image | is displayed) to quit. For example, try: sxpm-noX --zoom 8 --bgcolor darkblue \ /usr/share/doc/libXpm-noX-3.5.7/plaid_mask.xpm -- Charles Wilson volunteer libXpm-noX maintainer for cygwin 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. Then, run setup and answer all of the questions. *** 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: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
