Re: [PATCH] inform user if any postinstall script failed to run
On Aug 12 15:42, Christopher Faylor wrote: On Thu, Aug 12, 2010 at 08:31:24PM +0100, Andy Koppe wrote: On 12 August 2010 19:13, Christopher Faylor wrote: Index: res.rc === RCS file: /cvs/cygwin-apps/setup/res.rc,v retrieving revision 2.88 diff -u -r2.88 res.rc --- res.rc 6 Aug 2010 18:56:12 - 2.88 +++ res.rc 12 Aug 2010 19:27:22 - @@ -433,7 +433,9 @@ ICONIDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20 LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE ,7,0,258,8,NOT WS_GROUP -LTEXT The following errors occured executing postinstall scripts, I think you still need something like the above describing what is going on. +LTEXT These don't necessarily mean that affected packages will +fail to function properly, but if you do notice problems +please check /var/log/setup.log.full., Could this be put on the bottom? Does anyone else have opinions here? I think I have. The wording doesn't need to be overly alarming, but we should not say if you do notice problems It's in our all interest that problems *are* reported, even if the seem to be harmless. But who is going to decide whether or not a failing postinstall script is ok or not, if not we maintainers? So, The following errors occured executing postinstall scripts. These don't necessarily mean that affected packages will fail to function properly, but please check /var/log/setup.log.full and report any problems. sounds about right to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] inform user if any postinstall script failed to run
On 12 August 2010 20:42, Christopher Faylor wrote: On Thu, Aug 12, 2010 at 08:31:24PM +0100, Andy Koppe wrote: On 12 August 2010 19:13, Christopher Faylor wrote: Index: res.rc === RCS file: /cvs/cygwin-apps/setup/res.rc,v retrieving revision 2.88 diff -u -r2.88 res.rc --- res.rc 6 Aug 2010 18:56:12 - 2.88 +++ res.rc 12 Aug 2010 19:27:22 - @@ -433,7 +433,9 @@ ICON IDI_CYGWIN,IDC_HEADICON,SETUP_HEADICON_X,0,21,20 LTEXT Postinstall script errors,IDC_STATIC_HEADER_TITLE ,7,0,258,8,NOT WS_GROUP - LTEXT The following errors occured executing postinstall scripts, I think you still need something like the above describing what is going on. + LTEXT These don't necessarily mean that affected packages will + fail to function properly, but if you do notice problems + please check /var/log/setup.log.full., Could this be put on the bottom? I assume so, and I think it would make sense, but I'm afraid I won't be able to play around with this in the next couple of days. Andy
Re: gcc4-core PACKAGE BUG
On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. cheers, DaveK
Re: gcc4-core PACKAGE BUG
On Aug 13 20:31, Dave Korn wrote: On 08/08/2010 17:26, Corinna Vinschen wrote: Hi Dave, testing with the latest setup.exe I came across an error message in postinstall: gcc4-core.sh, exit code 126 Manuall testing turned up that the script /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh is not executable. Yep, I was aware of that, and have explained it on the list whenever it's come up, but now we've got a requester I'll have to fix it properly. I'll do a respin 4.3.4-4 over the weekend or so. Cool, thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: CygwinX at MS Terminalserver?
Am 12.08.2010 18:04, schrieb Jon TURNEY: On 12/08/2010 08:31, Steffen Sledz wrote: Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? You shouldn't change the rights on any of these, as this could affect the security or functioning of other cygwin apps. Fortunately, you shouldn't need to, as, provided each X server instance has a unique display number, everything should work :-) This seems not to be right. :( Here are the results of my tests: testuser0001 starts an X server using the item XWin Server from the start menu. This results in the creation of some files/dirs with these rights. snip $ ls -la /tmp /var/log /tmp: total 1 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:55 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 15:51 .. -r--r--r-- 1 testuser0001 Domain Users 11 Aug 13 08:54 .X0-lock drwxrwxrwt+ 1 testuser0001 Domain Users0 Aug 13 08:54 .X11-unix /var/log: total 2316 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:54 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 16:21 .. -rw-r--r-- 1 Administrator Administrators 139786 Aug 13 08:48 setup.log -rw-r--r-- 1 Administrator Administrators 2219958 Aug 13 08:48 setup.log.full -rw-r--r-- 1 testuser0001 Domain Users 4447 Aug 13 08:54 XWin.0.log snap Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 Now testuser0001 stops his server by using the Exit item from the server menu. After this the files/dirs look like this. snip $ ls -la /tmp /var/log /tmp: total 0 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:58 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 15:51 .. drwxrwxrwt+ 1 testuser0001 Domain Users 0 Aug 13 08:58 .X11-unix /var/log: total 2316 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:54 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 16:21 .. -rw-r--r-- 1 Administrator Administrators 139786 Aug 13 08:48 setup.log -rw-r--r-- 1 Administrator Administrators 2219958 Aug 13 08:48 setup.log.full -rw-r--r-- 1 testuser0001 Domain Users 4871 Aug 13 08:58 XWin.0.log snap Now testuser0002 tries to start a server. This results in an error popup: snip A fatal error has occured and Cygwin/X will now exit. Cannot open log file /var/log/XWin.0.log Please open /var/log/XWin.%s.log for more information. Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Contact: cygwin-xfree@cygwin.com Build Date: 2010-08-06 XWin was started with the following command-line: X :0 -multiwindow snap Where you may experience problems is if the X server crashes whilst being run by an Administrator, and then a non-Adminstrator user tries to run X server using the same display number, which will fail due being unable to remove the stale lock file and unix socket. Unfortunately, there is no obvious way to fix that without introducing a security hole (not that it is known to be secure anyhow) I think that's not the problem in this case. Steffen -- 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: CygwinX at MS Terminalserver?
cygwin-xfree-ow...@cygwin.com schrieb am 13.08.2010 09:13:44:
...
Am 12.08.2010 18:04, schrieb Jon TURNEY:
On 12/08/2010 08:31, Steffen Sledz wrote:
Does anyone has experiences running CygwinX at an MS
Terminalserver? We like to use it at one based on Windows
Server 2003 with NTFS.
Is it possible to run multiple XWin instances for multiple
user sessions in parallel?
Any suggestions how to setup the rights in /tmp, /var/log,
/var/run, etc.?
You shouldn't change the rights on any of these, as this could
affect the security or functioning of other cygwin apps.
Fortunately, you shouldn't need to, as, provided each X server
instance has a unique display number, everything should work :-)
This seems not to be right. :(
Maybe my way can help you. The following three lines are from my startup
script:
(1) OLDDPY=$(netstat -an | grep 0:60|tail -1|gawk -F: '{print
substr($2,3,2) }')
(2) DPY=$(expr $OLDDPY + 1)
(3) run Xwin :$DPY -dpi 75 -swcursor -logfile $HOME/$USER.log ... more
options
All X servers use a port 60xx, so line (1) lists all net connections and
greps the relevant 60xx lines. tail -1 gives the highest used 60xx port.
The gawk returns the relevant 2 digits. Those get assigned to OLDDPY
(old/last
display number). Line (2) simply adds 1 to OLDDPY and assigns that number
to DPY (you guess it, thats the new DISPLAY number ...). Line (3) starts
X(win) with the new $DPY number and the parameter --logfile
$HOME/$USER.log
assigns a different logfile for each user.
HTH
hjb
--
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/
XServer draws to incorrect window when using VirtuaWin
VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop manager for Windows that lets you switch between several virtual desktops, similar to those provided in KDE Gnome. When switching between desktops that have CygwinX windows open, occasionally the Xserver draws to the wrong window. This is difficult to describe, so will continue with an example: Using Windows 7, Cygwin/X v1.8.0 Steps to reproduce: 1) Install VirtuaWin from http://virtuawin.sourceforge.net/ 2) Start the CygwinX server 3) Open a (DOS) cygwin window 4) Type xterm twice, to open two xterm windows. Maximise these two windows to full screen. 5) Move one of these windows to desktop2 6) Type ping google.com -n 1000 to get a stream of data appearing in the xterm window on desktop2 7) Go back to desktop1, and make sure the DOS cygwin window is selected 8) Switch back to desktop2. The ping xterm window should be selected. 9) Switch back to desktop1. The cygwin window should be selected. What should happen: The empty xterm session on desktop1 should be displayed in the window behind the cygwin window What happens: The ping data stream appears in the xterm window on desktop1, and continues receiving updates every second. Selecting the xterm window causes the ping data to disappear and the empty xterm session to be displayed correctly. This is reproducible every time. The critical thing is that if the xterm window on desktop1 is not selected after a desktop switch, it shows the data from the xterm window on desktop 2. FWIW, this problem doesn't exist with xming, and I haven't seen the issue with any other applications. Any questions, please let me know. Thanks, Pete -- 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: CygwinX at MS Terminalserver?
On 13/08/2010 08:13, Steffen Sledz wrote: Am 12.08.2010 18:04, schrieb Jon TURNEY: On 12/08/2010 08:31, Steffen Sledz wrote: Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? You shouldn't change the rights on any of these, as this could affect the security or functioning of other cygwin apps. Fortunately, you shouldn't need to, as, provided each X server instance has a unique display number, everything should work :-) This seems not to be right. :( Here are the results of my tests: [snip] Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 This is expected. As I said, each X server instance must have a unique display number. This can't possibly work any other way. If two users both have an X server with display number 0, to which server should a client started with DISPLAY=:0.0 connect? Now testuser0001 stops his server by using the Exit item from the server menu. After this the files/dirs look like this. [snip] /var/log: total 2316 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:54 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 16:21 .. -rw-r--r-- 1 Administrator Administrators 139786 Aug 13 08:48 setup.log -rw-r--r-- 1 Administrator Administrators 2219958 Aug 13 08:48 setup.log.full -rw-r--r-- 1 testuser0001 Domain Users 4871 Aug 13 08:58 XWin.0.log snap Now testuser0002 tries to start a server. This results in an error popup: snip A fatal error has occured and Cygwin/X will now exit. Cannot open log file /var/log/XWin.0.log This is interesting. On my systems, /var/log has mode 777, rather than 1777. Having the restricted deletion flag set on /var/log prevents other users from deleting the logfile from a previous run. However, checking the source for setup.exe, I see that it does create /var/log with 1777 permissions, so how I got into this state I don't know... I'm not sure that is right, but assuming it is intentional, I guess we need to create a /var/log/xwin with mode 777 and arrange for that to be the default logfile location mkdir /var/log/xwin chmod 777 /var/log/xwin adding '-logfile /var/log/xwin/XWin.%s.log' to your xwin command line. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: CygwinX at MS Terminalserver?
Jon TURNEY jon.turney at dronecode.org.uk writes:
Where you may experience problems is if the X server crashes whilst being run
by an Administrator, and then a non-Adminstrator user tries to run X server
using the same display number, which will fail due being unable to remove the
stale lock file and unix socket. Unfortunately, there is no obvious way to
fix that without introducing a security hole (not that it is known to be
secure anyhow)
Hi,
this problem could be handled.
Create a script which checks for existence of the PID written into the
file(s) /tmp/.X${DISPLAY_NUMBER}-lock and remove the Lockfile and also
the Domainsocket for the same DISPLAY_NUMBER if the process doesn't exist.
It is a good strategy to check for the string Xwin in the process command
to ignore other processes which may got the same PID as the previous
XServer process.
Either do this periodically in the script itself and start it via inittab
or as a windows service, or run it via cron. Checking once a minute should
be sufficient.
regards
kf
--
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: X hardware acceleration still flaky?
On 12/08/2010 19:20, l.w...@surrey.ac.uk wrote: I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates: moving the geomview window up and/or to the left causes the crash, while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies. So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash. I can confirm that your replacement code drop (url below) appears to fix this crash problem. Thanks for testing. However, I have a question about your conclusion that this has nothing to do with opengl. If you start geomview under a buggy crashing XWin server with: geomview -noopengl (one dash, note spelling) there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension? Whilst this is the obvious conclusion to reach, it doesn't seem to be correct. Supplying -noopengl to geomview causes it to do different things, and in particular, it creates a different window hierarchy inside the camera window (which you can observe using xwininfo -tree on that camera window). It seems that the window hierarchy used when opengl is selected, happens to expose a bug in XWin, which causes composite to handle the window's position incorrectly. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: Re: xterm and 7-bit control codes
On 8:59 PM, Thomas Dickey wrote: As far as I know, xterm's never sent more than one byte for either x/y in a button event. Ditto for rxvt. It sounds like a useful idea, except that it would of course be incompatible with the existing applications. So it would have to be enabled by a new control sequence. Hehe... very true about breaking existing apps. All those years ago the extra octet kick-started everything by confusing emacs (well, xterm-mouse-mode, really). I started looking at the character stream and reverse-engineered the above formula while trying to get rid of all the ascii garbage that polluted my buffers after stray mouse clicks. Only then did I realize I could exploit (rather than suppress) the extra octets to make large terminals behave better... (On the other hand, whatever application you were using at the time may have translated the characters in that manner). I dug up an old .emacs, and it actually mentions gnu screen. If so, that's definitely been fixed because I specifically tested screen on several machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) before posting here. Any ideas what other terminal emulators I might test? Side note: how much pain would it be asking for if I tried to add the double-octet behavior to xterm as a feature? Would it be better to tackle rxvt? Or would it be man-weeks of work no matter what and I should just drop it? Thanks, Ryan *** testing gnome terminal was hilarious: enabling mouse support and clicking on the wrong position sends a control sequence containing ^Z, which duly backgrounds the app! -- 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: Re: xterm and 7-bit control codes
On Sat, 14 Aug 2010, Ryan Johnson wrote: On 8:59 PM, Thomas Dickey wrote: As far as I know, xterm's never sent more than one byte for either x/y in a button event. Ditto for rxvt. It sounds like a useful idea, except that it would of course be incompatible with the existing applications. So it would have to be enabled by a new control sequence. Hehe... very true about breaking existing apps. All those years ago the extra octet kick-started everything by confusing emacs (well, xterm-mouse-mode, really). I started looking at the character stream and reverse-engineered the above formula while trying to get rid of all the ascii garbage that polluted my buffers after stray mouse clicks. Only then did I realize I could exploit (rather than suppress) the extra octets to make large terminals behave better... (On the other hand, whatever application you were using at the time may have translated the characters in that manner). I dug up an old .emacs, and it actually mentions gnu screen. If so, that's definitely been fixed because I specifically tested screen on several machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) before posting here. Any ideas what other terminal emulators I might test? Not offhand. The only prior discussion I recall in that area was the 1-byte limit. It might have been someone's more/less private patch to screen - to be usable with screen in the first place, it has to be aware of the control sequence (otherwise it tends to filter things out). The mouse control sequences are a special case, since they don't have a final character. Side note: how much pain would it be asking for if I tried to add the double-octet behavior to xterm as a feature? Would it be better to tackle rxvt? Or would it be man-weeks of work no matter what and I should just drop it? It didn't sound like a lot of work: a case-statement entry in dpmodes (charproc.c) to enable/disable it, and a few lines of code in EditorButton (button.c) plus updating ctlseqs.ms). Thanks, Ryan *** testing gnome terminal was hilarious: enabling mouse support and clicking on the wrong position sends a control sequence containing ^Z, which duly backgrounds the app! ;-) -- 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/
src/winsup/cygwin ChangeLog cygheap.h path.cc ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-13 11:51:54 Modified files: winsup/cygwin : ChangeLog cygheap.h path.cc spawn.cc Log message: * cygheap.h (class cwdstuff): Make drive_length private. Add error member. (cwdstuff::get_error): New inline method. (cwdstuff::get_error_desc): Declare. (cwdstuff::set): Change first parameter to pointer to path_conv. * path.cc (chdir): Drop doit. Align call to cwdstuff::set to new arguments. (cwdstuff::init): Only call cwdstuff::set if it's not already initialized. Add comment. Drop third parameter in call to cwdstuff::set. (cwdstuff::set): Partially rewrite. Add lots of comments to explain everything. Drop doit since it's not used anymore. Always create new handle to CWD if not in a virtual path. Drop PEB locking when reading PEB values in init phase. Check for accessibility to set correct error code. Drop Vista workaround. Never write back into PEB. Set Win32 CWD to \\?\PIPE\ on init. Simplify creation of win32 path. Set new error member to a meaningful value. (cwdstuff::get_error_desc): New method to generate error message from cwd error code. * spawn.cc (spawn_guts): Call cwdstuff::get_error_desc to create more meaningful error message when not being able to start native Win32 app due to CWD restrictions. When starting native Win32 app, lock cwd and use in calls to CreateProcessW/CreateProcessAsUserW. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4991r2=1.4992 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygheap.h.diff?cvsroot=srcr1=1.145r2=1.146 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.599r2=1.600 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc.diff?cvsroot=srcr1=1.293r2=1.294
src/winsup/doc ChangeLog faq-programming.xml n ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-13 11:52:14 Modified files: winsup/doc : ChangeLog faq-programming.xml new-features.sgml overview2.sgml pathnames.sgml setup2.sgml Log message: * faq-programming.xml (faq.programming.win32-api): Remove simplicity. Add note and xrefs to User's Guide chapters explaining restrictions using the Win32 API. * new-features.sgml (ov-new1.7.6): Add note about Win CWD. * overview2.sgml (ov-hi-intro): Add note and xrefs about Win32 API restrictions. Tone down flexibility. * pathnames.sgml (pathnames-intro): Add xref to pathnames-win32-api section. (pathnames-win32-api): New section describing Win32 CWD restriction. * setup2.sgml (setup-env-ov): New sub-section. (setup-env-win32): Ditto, describing Win32 environment restriction. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.309r2=1.310 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-programming.xml.diff?cvsroot=srcr1=1.16r2=1.17 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.50r2=1.51 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/overview2.sgml.diff?cvsroot=srcr1=1.18r2=1.19 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/pathnames.sgml.diff?cvsroot=srcr1=1.55r2=1.56 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/setup2.sgml.diff?cvsroot=srcr1=1.43r2=1.44
src/winsup/utils ChangeLog mount.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-08-13 19:10:22 Modified files: winsup/utils : ChangeLog mount.cc Log message: * mount.cc (from_fstab): Fix potentially fatal typo. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.536r2=1.537 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/mount.cc.diff?cvsroot=srcr1=1.51r2=1.52
[PATCH] Create libpng.dll.a symlink on Cygwin/MinGW
From: Yaakov Selkowitz yselkow...@users.sourceforge.net --- Makefile.am |2 +- Makefile.in |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index e53fd96..6fb3322 100644 --- a/Makefile.am +++ b/Makefile.am @@ -119,7 +119,7 @@ install-exec-hook: cd $(DESTDIR)$(bindir); $(LN_S) $(PNGLIB_BASENAME)-config libpng-config @set -x;\ cd $(DESTDIR)$(libdir);\ - for ext in a la so s...@pnglib_major@@pnglib_mi...@.@PNGLIB_RELEASE@ sl dylib; do\ + for ext in a la so s...@pnglib_major@@pnglib_mi...@.@PNGLIB_RELEASE@ sl dylib dll.a; do\ rm -f libpng.$$ext;\ if test -f $(PNGLIB_BASENAME).$$ext; then\ $(LN_S) $(PNGLIB_BASENAME).$$ext libpng.$$ext;\ diff --git a/Makefile.in b/Makefile.in index 0afaa4a..4622a39 100644 --- a/Makefile.in +++ b/Makefile.in @@ -1243,7 +1243,7 @@ install-exec-hook: cd $(DESTDIR)$(bindir); $(LN_S) $(PNGLIB_BASENAME)-config libpng-config @set -x;\ cd $(DESTDIR)$(libdir);\ - for ext in a la so s...@pnglib_major@@pnglib_mi...@.@PNGLIB_RELEASE@ sl dylib; do\ + for ext in a la so s...@pnglib_major@@pnglib_mi...@.@PNGLIB_RELEASE@ sl dylib dll.a; do\ rm -f libpng.$$ext;\ if test -f $(PNGLIB_BASENAME).$$ext; then\ $(LN_S) $(PNGLIB_BASENAME).$$ext libpng.$$ext;\ -- 1.7.1 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mintty versus xterm colors in Vim
On 12 August 2010 19:56, Andy Koppe wrote: Looks like vim automatically enables 256-color mode in xterm. Invoke vim with TERM=xterm-256color to enable it in mintty too. (You can set that variable on the 'Output' page of mintty's options. Requires a restart of mintty to take effect.) Marvellous ! Best regards. Jean Johner -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.5-1: backspace does not work correctly...
On Tue, 20 Apr 2010 10:03:19 +0200, Corinna Vinschen wrote: Did you work in xterm or the Linux console lately? Try pressing Ctrl-V Backspace in both of them. You'll see ^?, not ^H. I see ^H (because I have set it up so that when I press the backspace key, I actually get a backspace, and not a !...@#$%^* ASCII delete). This takes patching and recompiling several packages, but hey, that is why I use Gentoo. On Tue, 20 Apr 2010 00:12:29 +0100, Andy Koppe wrote: From the cygwin-1.7.5 release announcement: - Support DEC Backarrow Key Mode escape sequences (ESC [ ? 67 h, ESC [ ? 67 l) in Windows console. (The first one switches to ^H. You'll need to set stty erase accordingly.) Can you please enlighten the uninformed (me) how to set this up in Cygwin? Getting ^? whenever I press backspace makes it quite unusable (to me) at present. Nuzhna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Change to gnuplot's handling of ^Z and ^C
Hi all, Recenty I noticed that gnuplot no longer responds instantly to control characters. You have to hit an additional key before they take effect. So, for example, if I type ^Zdfg\n I get the following: gnuplot ^Z [1]+ Stopped(SIGTSTP)gnuplot [r...@scovich] ~/experiments $ fg gnuplot d Notice that gnuplot, not bash, got the 'd'... I've also managed to close my terminal on accident once or twice, but I don't know what exact key sequence did it (it may have had something to do with ^S enabling flow control instead of starting a search in emacs, because the latter failed to come to fg when gnuplot slurped up the 'f'). Maybe it's some strange interaction between bash's readline and gnuplot's? The shell isn't affected, nor are non-readline utilities like cat and emacs. Thoughts? Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Postinstall script errors
On Aug 12 19:50, Tilman Hausherr wrote: On Thu, 12 Aug 2010 11:59:30 +0200, Corinna Vinschen wrote: That's probably a fault in the postinstall scripts. It would be nice if you could provide more details about what fails exactly in the script, or better, what in the script has a non-0 exit code. That would help us lazy maintainers to fix the scripts faster. Keep in mind that the dialog providing info about failing postinstall scripts is very new. I'm quite sure that we have a couple of scripts which return with a non-0 exit code but the maintainers just don't know it yet, and I don't take myself out of the picture. I'm not sure if these faulty postinstall scripts are really THAT important, I got zero reaction on a bug report with details http://sourceware.org/ml/cygwin/2010-08/msg00158.html and I found out in the meantime that it was already reported in january and was already a known error at that time. http://old.nabble.com/gcc-command-not-found-td27393452.html#a27395128 I reported this myself a couple of days ago on the cygwin-apps list. http://cygwin.com/ml/cygwin-apps/2010-08/msg00074.html Dave? Any word on this? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Incomplete installation of subversion
Greetings, Corinna Vinschen! On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: (snip) stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: Of course. It's just you can't launch it after wget - file don't have rights to execute it. chmod +x ? Indeed, yet again, it's not the point of my question. I have download manager processing downloads from my web browser. It's quite enough for me. When server behave correctly. -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.08.2010, 14:26 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
XWin shows in ps -a but not in ps
I have XWin running and it shows up as a process under ps -a but not under ps I think this behaviour is recent: certainly it has perturbed what were previously well-behaved scripts. Supplementary: I was basically using ps | grep in a script to query whether XWin was running. Am I correct that there is a procedure built in that will achieve this? Thank you. Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CygWin Security Performance Issues
On Thu, Aug 12, 2010 at 11:55 AM, Corinna Vinschen wrote: Really? As far as I understood from the docs, SUA is rather styled after SVR4. Looks like I got it into my head that if a Unix isn't GNU, it must be BSD. Obviously, I was wrong * * Wrong, said Renner. The tactful way, Rod said quietly, the polite way to disagree with the Senator would be to say, `That turns out not to be the case.' -- Niven and Pournelle, The Mote In God's Eye -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.5-1: backspace does not work correctly...
On 13 August 2010 10:20, Nuzhna Pomoshch wrote: On Tue, 20 Apr 2010 00:12:29 +0100, Andy Koppe wrote: From the cygwin-1.7.5 release announcement: - Support DEC Backarrow Key Mode escape sequences (ESC [ ? 67 h, ESC [ ? 67 l) in Windows console. (The first one switches to ^H. You'll need to set stty erase accordingly.) Can you please enlighten the uninformed (me) how to set this up in Cygwin? echo -ne '\e[?67h' stty erase ^H Or use mintty, which has a setting for this in its options dialog. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: XWin shows in ps -a but not in ps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2010 05:01 AM, Fergus wrote: I have XWin running and it shows up as a process under ps -a but not under ps Time for another round of the blame game! What's happening is that your shell is getting instantiated on a new vty. Even on my /linux/ box, ps only ever shows up with what's running under the child of my shell, so its not ps's fault, its more than likely /XWin's/ fault for how it handled shells before. More than likely however is that in your ~/.bashrc at one point before was the line alias ps='ps -a' Even I have a few lines like that: alias egrep='egrep --color=auto' alias ls='ls --color=auto' alias ll=' ls -alF' - -- Morgan Gangwere 0 dotpunct fractalus atpunct gmail dotpunct com http://sonof.bandit.name/ あなたのお母さんは、ハムスターとあなたの父エルダーベリーのワカサギでした - - A frenchman. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMZTmMAAoJEEURiCSotvJD05oP/22AgyBPJFmOq02DwFXqCHZu bUVuGJgaOttu28VvuqZnBiFyHFkZaPoQL4wlqoG0NDVLgqm3EAJHwZIDKK3fvt69 zn8mNaljNaQxwid4ERak8v53pBjIT8QwHh6CXWn8X+Kuto+cZoSl9qMlYl71cIv9 +eh7zLTTeZm2VydhCnVhqk4lcHZCyUHaGcX6md8YlHOiJKuv9xho7WF8g/kHFuCA IJXeenCcVMQdcrUvC25mMzEkjlJZkv+VgVCsObV5085imPJqsVI8CJFwomsIXPpz NX/jG17p9Ws/NmadhLUV9I0XnE/Us0y0CGS/fywerI3iHExAWB8M9+N/lRhoN1hD 2m7sLXG0WI9wgfnnT0Co6L5uGs5IwGlPpq5Bgvfesh2+6nmNeXwkEc0qiOiafnar m4uIUfMQsG3/11ocaVijIJibXVsMAXLmmAphN3JuniavR+Z8SYZs8WCIH2z9dKFM 5UhpadRngtDIg2yHFlROrgYVamLdwKfHmQdHL8qOTsUQyUEm65PDR4Sx6YPWJG+0 3tIqQKTVsRd8uNEjlN+EdvFH537zBu7Q5pgJvb0iMuB0+2jssipdYaxB5U5H1IFW w3MlyKaNj6l2XJMQCE0HFeztdzhMwSDNoExoCHqBR1FEBUuhBHTL3u7oCdggkfM7 bT2NDmPk5eCn15+h4lQr =khr/ -END PGP SIGNATURE- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libpng14-devel does not provide libpng.dll.a
On 8/12/2010 11:30 PM, Yaakov (Cygwin/X) wrote: libpng14-devel provides libpng.a and libpng.la symlinks, but no libpng.dll.a symlink. I presume this is unintentional? Yes. They changed the way these symlinks were done, to this: for ext in a la so s...@pnglib_major@@pnglib_mi...@.@PNGLIB_RELEASE@ sl dylib; do\ but dll.a is missing from that list. I'll roll out a replacement Sunday. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
On 08/12/2010 06:35 PM, Pedro Izecksohn wrote: --- I wrote: Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h My previous diff is wrong. The right one follows: OK, that documents _what_ your changes are, but not _why_ you are making them. Mentioning that you are adding macros that are present in a Linux installation's endian.h would have been nice (for example, that you made your changes by reading 'man htobe16' on Linux). + #ifdef _BSD_SOURCE + + #include byteswap.h + + #if __BYTE_ORDER == __LITTLE_ENDIAN Umm - did you copy straight from glibc's endian.h? That's a no-no; cygwin generally doesn't want to borrow LGPL sources to avoid any licensing questions (borrowing from BSD is okay, on the other hand). You would have to implement things from scratch from a documentation page, or copy from a less-questionable source, rather than using glibc's implementation. I'm stopping right here, so I don't risk tainting myself. How about you instead describe which macros you are missing, so someone can do a clean-room implementation of those macros. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Mode dependent cursor shape lost in cygwin Vim in a Windows console
Hello, Please do the following: 1/ Start a standard cmd console Launch Windows Vim (C:\Program Files\vim\vim72\vim.exe) with vim -u NONE file1 Result: file1 opens with a block cursor. If insert mode is activated, the cursor changes to underscore (nice) 2/ Launch cygwin.bat Launch cygwin Vim with vim -u NONE file1 Result: file1 is opened with an underscore cursor. No change when insert mode is activated. Is there a way to have mode dependent cursor shape in Cygwin Vim in a Windows console? Best regards. Jean Johner -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
bash becomes a directory in win 7? LOL
I'm trying to popup new bash windows from a script and getting lots of wierd problems. First, I seem to have to run the cygwin window as admin, ok fine I can click on that. After playing around for a while, I was able to get cmd start bash to run ok but the children seemed to lose admin startus if I closed the parent. Anyway, at some point they stopped working and I checked cygwin/bin and apparently bash was now a directory. If I copied bash.exe over it things started working again? I moved the old bash dir to bash_wtf and now if is called bash_wtf.exe and appears as a dir. Something up with links? Thanks, pointing out something obvious and stupid is welcome as long as it fixes the problem, LOL -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: libpng14-devel does not provide libpng.dll.a
Charles Wilson cygwin at cwilson.fastmail.fm writes: but dll.a is missing from that list. I'll roll out a replacement Sunday. I already took care of it upstream. Glenn -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash becomes a directory in win 7? LOL
On 8/13/2010 9:32 AM, mike marchywka wrote: I'm trying to popup new bash windows from a script and getting lots of wierd problems. First, I seem to have to run the cygwin window as admin, ok fine I can click on that. After playing around for a while, I was able to get cmd start bash to run ok but the children seemed to lose admin startus if I closed the parent. Anyway, at some point they stopped working and I checked cygwin/bin and apparently bash was now a directory. If I copied bash.exe over it things started working again? I moved the old bash dir to bash_wtf and now if is called bash_wtf.exe and appears as a dir. Something up with links? Thanks, pointing out something obvious and stupid is welcome as long as it fixes the problem, LOL Sounds like a bug in your scripts or a virus. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash postinstall script returns an error
On Thu, Aug 12, 2010 at 6:14 PM, cy.20.superconduc...@xoxy.net wrote: I was going to mention passwd-grp.sh, but I see there's already a thread for that, so I'll move right on to the next one. When I run setup.exe I always get an error for the bash.sh postinstall script, it seems to be on the line of: /bin/test -e /dev/stdin || ln -s /proc/self/fd/0 /dev/stdin || result=1 I'm not so clear as to why this fails. test returns a status of 1 when the script is run by the installer, and yet /dev/stdin does exist. setup.log.full contains a predictable ln: creating symbolic link `/dev/stdin': File exists. If I run the postinstall script manually, test gives a status of 0, stdin is left alone and the script runs to the end successfully - it only fails when run from inside the installer (2.712) for me. I've tried invoking bash for the script using the same switches as those reported in setup.log.full, but it still runs fine when done manually. I saw the exact same results. I didn't mention it in the other thread because the error didn't occur on manual run. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
--- Eric Blake ebl...@... wrote: Umm - did you copy straight from glibc's endian.h? That's a no-no; cygwin generally doesn't want to borrow LGPL sources to avoid any licensing questions (borrowing from BSD is okay, on the other hand). You would have to implement things from scratch from a documentation page, or copy from a less-questionable source, rather than using glibc's implementation. I'm stopping right here, so I don't risk tainting myself. How about you instead describe which macros you are missing, so someone can do a clean-room implementation of those macros. I did not copy my code from glibc's endian.h: I wrote my code yesterday, while on Windows Vista for 32 bits using joe on Cygwin and notepad. Now I'm using Ubuntu for x86-64. I'm also surprised that glibc's code is similar to mine: glibc's folks wrote: #ifdef __USE_BSD /* Conversion interfaces. */ # include bits/byteswap.h I wrote: #ifdef _BSD_SOURCE #include byteswap.h The man 3 page, from Linux and from the web, does not tell about __USE_BSD. The next line is equal, probably because the glibc's guy who wrote it also was using x86-32. If I would be using Ubuntu for x86-64 yesterday I would have written the opposite. #if __BYTE_ORDER == __LITTLE_ENDIAN If you want, to swap the order of my macros is very easy. Then glibc continues, interleaving be with le, and a pair of hto with another pair of toh: # define htobe16(x) __bswap_16 (x) # define htole16(x) (x) # define be16toh(x) __bswap_16 (x) # define le16toh(x) (x) It is very different from what I wrote. I interleaved the types: #define htobe16(x) bswap_16(x) #define htobe32(x) bswap_32(x) #define htobe64(x) bswap_64(x) To use bswap to implement hto and toh macros is the most intelligent approach. Fortunately, glibc's __bswap_16 differs from Cygwin's bswap_16. Also: glibc's style is different from mine: They use a space between the # and the define. After writing this message I'm proud that I'm as smart as the glibc's coder. I need the 64 bits macros only. I wrote the other macros for completeness. In my project, that can not be disclosed now, I use the arpa/inet.h macros for the smaller types. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Incomplete installation of subversion
On 13 August 2010 11:27, Andrey Repin wrote: Greetings, Corinna Vinschen! On Thu, Aug 12, 2010 at 9:02 AM, Andrey Repin wrote: (snip) stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: Of course. It's just you can't launch it after wget - file don't have rights to execute it. chmod +x ? Indeed, yet again, it's not the point of my question. I have download manager processing downloads from my web browser. It's quite enough for me. When server behave correctly. There's nothing wrong (in this regard) with the server. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html | In HTTP, it SHOULD be sent whenever the message's length can be | determined prior to being transferred You forced it to use gzip encoding, which is often a streaming process, and in general a server won't know in advance how long the content will be. Remove the -H (and -I) and curl works just fine (and the content is shorter than the gzipped version). In fact, curl works just fine even with the -H option, as long as you remove the -I, and remember to gunzip the contents. You had the choice of: a) criticizing the set-up of one of the web's largest and most reliable download sites or b) pausing to consider whether perhaps you'd missed something in your HTTP class I think perhaps you made the wrong choice. Phil -- -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.08.2010, 14:26 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7: why there is a directory E/cygwin/dev in the tree of cygwin ?
[reviving an old thread, relevant to today's current bash postinstall failures] On 03/17/2010 12:28 PM, Corinna Vinschen wrote: On Mar 17 12:21, Eric Blake wrote: On 03/17/2010 02:19 AM, rolandc wrote: I do not understand why the postinstall script bash.sh is so complex DEVDIR=$(cygpath -au C:/$(cygpath -am /dev/) | sed 's|/c/\(.\):/|/\1/|') mkdir -p $DEVDIR || result=1 it would be simple (too simple?) to mkdir -p /dev || result=1 Yes, it would be too simple. /dev already exists, so the mkdir would fail to do anything useful. We REALLY want to create the underlying Windows directory at the same location at where /dev would be mounted, and to do that, we really do want to know the windows location (drive letter and all) of /. Then, by using mkdir of that fancy windows path that happens to live at the same place as where /dev normally resolves to, then we can guarantee that /dev/stdin gets created as an actual symlink in the windows heirarchy (since it does NOT resolve via the /dev magic mount point), and that tab-completion can see any contents placed into the windows counterpart directory. Nothing of this should be necessary since the 000-cygwin-post-install.sh script from the base-cygwin package already creates /dev. Interesting - cygwin 1.7 is much nicer in regards to letting 'mkdir /dev' succeed without having to go through cygpath hoops. I'm building a new bash package now that should fix all this mess, by using the same means as 000-cygwin-post-install.sh to populate necessary entries into /dev. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash postinstall script returns an error
On 08/12/2010 06:14 PM, cy.20.superconduc...@xoxy.net wrote: I was going to mention passwd-grp.sh, but I see there's already a thread for that, so I'll move right on to the next one. When I run setup.exe I always get an error for the bash.sh postinstall script, it seems to be on the line of: /bin/test -e /dev/stdin || ln -s /proc/self/fd/0 /dev/stdin || result=1 I'm not so clear as to why this fails. test returns a status of 1 when the script is run by the installer, and yet /dev/stdin does exist. setup.log.full contains a predictable ln: creating symbolic link `/dev/stdin': File exists. Aha. I finally figured out why. The postinstall script is run with stdin closed, but when you run it by hand, unless you did the redirection -, you run with stdin open. test -e /dev/stdin fails if it is a dangling symlink (which it is when stdin is closed), which then tries the ln but that fails because the dangling symlink is in the way. I should really be using test -h. $ test -e /dev/stdin; echo $? 0 $ test -e /dev/stdin -; echo $? 1 $ test -h /dev/stdin; echo $? 0 $ test -h /dev/stdin -; echo $? 0 Thanks for insisting that I fix this. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Mounting shares that require passwords
Is there some way within cygwin to successfully mount a share that requires a password. Until I run the net use command or other Windows application to open the share with the password Cygwin is unable to access it. The best I've come up with so far is to run the net use from my .bashrc. Is there a better way to handle this? Regards, Steven -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mode dependent cursor shape lost in cygwin Vim in a Windows console
On 13 August 2010 14:22, JOHNER Jean 066030 wrote: Hello, Please do the following: 1/ Start a standard cmd console Launch Windows Vim (C:\Program Files\vim\vim72\vim.exe) with vim -u NONE file1 Result: file1 opens with a block cursor. If insert mode is activated, the cursor changes to underscore (nice) 2/ Launch cygwin.bat Launch cygwin Vim with vim -u NONE file1 Result: file1 is opened with an underscore cursor. No change when insert mode is activated. Is there a way to have mode dependent cursor shape in Cygwin Vim in a Windows console? No, but I'm sure a patch implementing the DECSCUSR control sequence using SetConsoleCursorInfo() would be welcome. (Copyright assignment required.) http://vt100.net/docs/vt510-rm/DECSCUSR http://msdn.microsoft.com/en-us/library/ms686019.aspx Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mounting shares that require passwords
On 8/13/2010 11:24 AM, Steven Collins wrote: Is there some way within cygwin to successfully mount a share that requires a password. Until I run the net use command or other Windows application to open the share with the password Cygwin is unable to access it. The best I've come up with so far is to run the net use from my .bashrc. Is there a better way to handle this? Cygwin doesn't really mount anything. It just creates a path translation table which is used to convert POSIX paths into their equivalent Windows paths. So if you need to enter a password to access the share using a Windows program or net use the path first, the same will be true for Cygwin. -Jeremy signature.asc Description: OpenPGP digital signature
Re: Mounting shares that require passwords
On Fri, Aug 13, 2010 at 10:28, Jeremy Bopp wrote: On 8/13/2010 11:24 AM, Steven Collins wrote: Is there some way within cygwin to successfully mount a share that requires a password. Until I run the net use command or other Windows application to open the share with the password Cygwin is unable to access it. The best I've come up with so far is to run the net use from my .bashrc. Is there a better way to handle this? Cygwin doesn't really mount anything. It just creates a path translation table which is used to convert POSIX paths into their equivalent Windows paths. So if you need to enter a password to access the share using a Windows program or net use the path first, the same will be true for Cygwin. -Jeremy It would be nice though if Cygwin would recognize that it was trying to access a share and that a password is required. I've actually run into an issue with my net use solution. Under cygwin the command will prompt me for my password, but then it immediately fails for a bad password. I'm never actually given a chance to enter the password. If I enter the password on the command line the command succeeds, but that is not an acceptable solution as it means my password is in the clear. Any ideas on why this is happening? Regards, Steven -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mounting shares that require passwords
On Fri, Aug 13, 2010 at 10:56:55AM -0600, Steven Collins wrote: On Fri, Aug 13, 2010 at 10:28, Jeremy Bopp wrote: On 8/13/2010 11:24 AM, Steven Collins wrote: Is there some way within cygwin to successfully mount a share that requires a password. Until I run the net use command or other Windows application to open the share with the password Cygwin is unable to access it. The best I've come up with so far is to run the net use from my .bashrc. Is there a better way to handle this? Cygwin doesn't really mount anything. ?It just creates a path translation table which is used to convert POSIX paths into their equivalent Windows paths. ?So if you need to enter a password to access the share using a Windows program or net use the path first, the same will be true for Cygwin. It would be nice though if Cygwin would recognize that it was trying to access a share and that a password is required. Cygwin is a general-purpose DLL. It can't stop what it is doing and ask the user for input. I've actually run into an issue with my net use solution. Under cygwin the command will prompt me for my password, but then it immediately fails for a bad password. I'm never actually given a chance to enter the password. If I enter the password on the command line the command succeeds, but that is not an acceptable solution as it means my password is in the clear. Any ideas on why this is happening? Probably you're trying to run the net use command from a pty in mintty, rxvt, or ssh and net use doesn't recognize cygwin ptys. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mounting shares that require passwords
On Fri, Aug 13, 2010 at 11:07, Christopher Faylor wrote: On Fri, Aug 13, 2010 at 10:56:55AM -0600, Steven Collins wrote: On Fri, Aug 13, 2010 at 10:28, Jeremy Bopp wrote: On 8/13/2010 11:24 AM, Steven Collins wrote: Is there some way within cygwin to successfully mount a share that requires a password. Until I run the net use command or other Windows application to open the share with the password Cygwin is unable to access it. The best I've come up with so far is to run the net use from my .bashrc. Is there a better way to handle this? Cygwin doesn't really mount anything. ?It just creates a path translation table which is used to convert POSIX paths into their equivalent Windows paths. ?So if you need to enter a password to access the share using a Windows program or net use the path first, the same will be true for Cygwin. It would be nice though if Cygwin would recognize that it was trying to access a share and that a password is required. Cygwin is a general-purpose DLL. It can't stop what it is doing and ask the user for input. I've actually run into an issue with my net use solution. Under cygwin the command will prompt me for my password, but then it immediately fails for a bad password. I'm never actually given a chance to enter the password. If I enter the password on the command line the command succeeds, but that is not an acceptable solution as it means my password is in the clear. Any ideas on why this is happening? Probably you're trying to run the net use command from a pty in mintty, rxvt, or ssh and net use doesn't recognize cygwin ptys. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple I'm attempting to execute net use from the bash command prompt in an xterm session that was started via the XWin Server menu item. The 'ps' command lists the TTY as con, so I wouldn't expect to be using a pty. Am I? If so, is there a work around for the problem? I have noticed that even if I start a cmd session from cygwin that the problem persists. Regards, Steven -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mounting shares that require passwords
On 8/13/10 10:13 AM, Steven Collins wrote: I'm attempting to execute net use from the bash command prompt in an xterm session that was started via the XWin Server menu item. The 'ps' command lists the TTY as con, so I wouldn't expect to be using a pty. Am I? If so, is there a work around for the problem? I have noticed that even if I start a cmd session from cygwin that the problem persists. Anything that's not a real Windows console window is a pty as far as Cygwin is concerned, and a plain pipe as far as win32 is concerned. Starting a cmd doesn't fix the issue because that cmd is still talking to what it sees as a pipe. You can just start a new console window for net use with cygstart; I believe specifying the password on the command line should be fine. Another option is trying the conin program, which uses black magic to give a program a real console for input. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: bash-3.2.51-24
A new release of bash, 3.2.51-24, has been uploaded and will soon reach a mirror near you. This replaces 3.2.49-23 as current. NEWS: = This is a minor update that pulls in a couple of upstream patches and fixes a bug in the postinstall script. There are a few things you should be aware of before using this version: 1. When using binary mounts, cygwin programs try to emulate Linux. Bash on Linux does not understand \r\n line endings, but interprets the \r literally, which leads to syntax errors or odd variable assignments. Therefore, you will get the same behavior on Cygwin binary mounts by default. 2. d2u is your friend. You can use it to convert any problematic script into binary line endings. 3. Cygwin text mounts automatically work with either line ending style, because the \r is stripped before bash reads the file. If you absolutely must use files with \r\n line endings, consider mounting the directory where those files live as a text mount. However, text mounts are not as well tested or supported on the cygwin mailing list, so you may encounter other problems with other cygwin tools in those directories. 4. This version of bash has a cygwin-specific shell option, named igncr to force bash to ignore \r, independently of cygwin's mount style. As of bash-3.2.3-5, it controls regular scripts, command substitution, and sourced files. I hope to convince the upstream bash maintainer to accept this patch into the future bash 4.0 even on Linux, rather than keeping it a cygwin-specific patch, but only time will tell. There are several ways to activate this option: 4a. For a single affected script, add this line just after the she-bang: ~ (set -o igncr) 2/dev/null set -o igncr; # comment is needed 4b. For a single script, invoke bash explicitly with the shopt, as in 'bash -o igncr ./myscript' rather than the simpler './myscript'. 4c. To affect all scripts, export the environment variable BASH_ENV, pointing to a file that sets the shell option as desired. Bash will source this file on startup for every script. 4d. Added in the bash-3.2-2 release: export the environment variable SHELLOPTS with igncr included in it. It is read-only from within bash, but you can set it before invoking bash; once in bash, it auto-tracks the current state of 'set -o igncr'. If exported, then all bash child processes inherit the same option settings; with the exception added in 3.2.9-11 that certain interactive options are not inherited in non-interactive use. 5. You can also experiment with the IFS variable for controlling how bash will treat \r during variable expansion. 6. The bash hack for honoring the underlying mount point of DOS-style paths has been discontinued, as had been promised in several prior release notes. Use POSIX-style paths instead. 7. There are varying levels of speed at which bash operates. The fastest is on a binary mount with igncr disabled (the default behavior). Next would be text mounts with igncr disabled and no \r in the underlying file. Next would be binary mounts with igncr enabled. And the slowest that bash will operate is on text mounts with igncr enabled. 8. If you don't like how bash behaves, then propose a patch, rather than proposing idle ideas. This turn of events has already been talked to death on the mailing lists by people with many ideas, but few patches. 9. If you forget to read this release announcement, the best you can expect when you complain to the list is a link back to this email. Remember, you must not have any bash or /bin/sh instances running when you upgrade the bash package. This release requires cygwin-1.7.5-1 or later; and it requires libreadline7-6.0.3-1 or later. See also the upstream documentation in /usr/share/doc/bash/. DESCRIPTION: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash, similar to some Linux distributions (although /bin/sh may swap to dash at some future time). UPDATE: === 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 and pick up 'bash' in the 'Base' category (it should already be selected). DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin bash maintainer CYGWIN-ANNOUNCE
Re: cygwin 1.7: why there is a directory E/cygwin/dev in the tree of cygwin ?
Eric Blake wrote: [reviving an old thread, relevant to today's current bash postinstall failures] ... I'm building a new bash package now that should fix all this mess, by using the same means as 000-cygwin-post-install.sh to populate necessary entries into /dev. Splendid! Just for the record, I noticed this over a year ago: http://cygwin.com/ml/cygwin/2009-07/msg00944.html So, proof that we don't need a bug tracker - mailing lists work fine! The change to check postinstall exit codes is likely to throw up a few more buglets yet, but looks like it will be well worth the pain. [Now, I'm just waiting for something completely different: http://cygwin.com/ml/cygwin/2009-12/msg00298.html ] -- Cliff -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Incomplete installation of subversion
Greetings, Phil Betts! stdout:curl -iI -H Accept-Encoding: gzip -s -- http://cygwin.com/setup.exe; HTTP/1.1 200 OK Date: Thu, 12 Aug 2010 06:59:40 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Tue, 10 Aug 2010 16:28:21 GMT ETag: 18e01b8-a7413-9f101340 Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=0 Expires: Thu, 12 Aug 2010 06:59:40 GMT Content-Type: application/octet-stream Works for me with wget: Of course. It's just you can't launch it after wget - file don't have rights to execute it. chmod +x ? Indeed, yet again, it's not the point of my question. I have download manager processing downloads from my web browser. It's quite enough for me. When server behave correctly. There's nothing wrong (in this regard) with the server. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html | In HTTP, it SHOULD be sent whenever the message's length can be | determined prior to being transferred RFC 2119 is my most loved document. :) I know the meaning of these words, and as my experience over fifteen years suggest, the proper Content-Length header for downloadable content is more common across the internet. Your site is only third in these years that don't know what it's doing. And I don't really care about it's size or respect someone else put into it. I do respect it highly, trust me, else i'd not bother reporting issues with it. You forced it to use gzip encoding, I *suggested*, not forced. And since server accepted suggestion, I expect it to have proper headers in response. which is often a streaming process, and in general a server won't know in advance how long the content will be. Not for downloadable content, again. The HTML page transfer is often a stream, yes (not all of the server-side processors have ability to pack the output, and not all of the site owners choose to use this ability, even if it present, due to considerable CPU usage increase). For downloadable content, the size is known beforehand in most cases. Remove the -H (and -I) and curl works just fine (and the content is shorter than the gzipped version). I know, that's how I've discovered the issue. In fact, curl works just fine even with the -H option, as long as you remove the -I, and remember to gunzip the contents. curl, yes, I know that... Ah well, let's round up the discussion, it's leading to nowhere, it seems. You had the choice of: a) criticizing the set-up of one of the web's largest and most reliable download sites or b) pausing to consider whether perhaps you'd missed something in your HTTP class I think perhaps you made the wrong choice. -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.08.2010, 21:40 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem with -D_GLIBCXX_DEBUG and cppcheck
On my Linux machine I'm using the latest cppcheck from git since it has bug fixes I need to test my code. Now that it's mostly working I tried to compile it on Cygwin so I would have it available there as well. I ran into a few problems and after some debug it appears to be a problem with the -D_GLIBCXX_DEBUG flag. My cppcheck bug report for this can be found here: https://sourceforge.net/apps/trac/cppcheck/ticket/1929. I'm not a cppcheck maintainer so I can't provide much more help than submitting this report. This is using the latest Cygwwin running on Windows XP Pro SP 3 32 bit. CYGWIN_NT-5.1 cdr-laptop 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin g++ (GCC) 4.3.4 20090804 (release) 1 If you need more information please let me know. You should be able to reproduce the test crash just by compiling and testing (make test) the latest code from git (git clone git://github.com/danmar/cppcheck.git) since it has the -D_GLIBCXX_DEBUG flag already set. This has not been noticed with the actual releases on Cygwin since cppcheck only uses that flag during development. Cary -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
copying from desktop to server changes group and permissions
Hello, when I copy a file from my desktop to the location on our server, it changes permissions and group from root to Domain Users ls -l tree.eps -rw--- 1 977315 root 69488 2010-06-06 21:02 tree.eps /home/The-Works/invention-disclosures+patents/1590--networked-shh-channels ls -l /z/tmp/tree.eps -rwxrwxrwx+ 1 977315 Domain Users 69488 2010-08-13 14:12 /z/tmp/tree.eps* /home/The-Works/invention-disclosures+patents/1590--networked-shh-channels I cannot use chmod or chown to modify either the group or the permissions. I think that affects the behavior of tar and cpio as well. I tried reading the security part of the manual (http://cygwin.com/cygwin-ug-net/ntsec.html), but my eyes soon lost focus. Is that where the answer lies? Thanks, Mirko -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
mount segfaults with missing EOL in fstab
Hello. I have just noticed that the mount utility segfaults when the last line of /etc/fstab is incorrectly terminated with a missing LF, even if it is a comment line. $ mount -a Segmentation fault (core dumped) -- Vincent Rivière -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mount segfaults with missing EOL in fstab
On Aug 13 20:32, Vincent Rivière wrote: Hello. I have just noticed that the mount utility segfaults when the last line of /etc/fstab is incorrectly terminated with a missing LF, even if it is a comment line. $ mount -a Segmentation fault (core dumped) Thanks for the hint. Due to a typo, mount accidentally dereferenced a pointer which could be NULL. Fixed in CVS. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: experimental package: gcc4-4.5.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This package is a test release, owing to regressions with the Ada language, and because it is the first package from a new upstream GCC release series. A full release of GCC-4.5.1 will follow shortly. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = 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.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is an experimental release, any gcc packages you currently have installed will *not* be automatically selected for update to the new version; you will need to select the manually, or use the Exp view of setup's chooser display and disable any other undesired experimental packages. Note also that on next running setup.exe, experimental packages are by default selected for roll-back to the current version; they must be manually deselected in order to retain them. NEWS From the README: (with some minor tweaks added in passing). gcc4-4.5.0-1 - -- This is the first release of the GCC 4 compiler package for Cygwin from the latest upstream GCC release series, version 4.5.0. As with previous Cygwin GCC packages, all the major runtime libraries are implemented as DLLs as well as static archives. It can fully co-exist side-by-side with the older Cygwin gcc-3.4.4 series compiler. All languages are supported, although Ada and Java remain works-in-progress. Because of the regressions in Ada, and in order to give any bedding-in problems from the first release of a new release series, this is a test release. I hope to follow it soon by a full release with Ada working. (... continues ...) WARNING: Experimental release, potential back-compat issues or ABI breaks. == As mentioned above, Ada is known to have regressions. As this is all still experimental, please watch out for bugs. Anything abnormal should be reported, in the first instance, to the main Cygwin mailing list. Cygwin port maintained by: Dave Korn dave.korn.cyg...@gmail.com.use.the.list.please Please address all questions to the Cygwin mailing list at cygwin@cygwin.com This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cyg...@gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - - - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh R4l4Ae3Lpgduv7V4ssz15qOGPAe++FmbutyYjF2mxwvwX86coWnkarkhuTrwoB29 Mb9IAqqpWcLqdSzUof5XSm4hesB8PASC5hCJ3D6ztMTX3OOEywSt8LJlOvgaM/YZ fSit+5xVfGG9AXZya+jKjJnJBCyiqdWZslfRLaSHDF4M4roDk2cl8SxVJTMiBl5g
Broken process substitution
Try echo hello (cat) -- that's supposed to output hello. On Cygwin, we get bash: echo: write error: Bad file descriptor -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Broken process substitution
On 08/13/2010 02:04 PM, Daniel Colascione wrote: Try echo hello (cat) -- that's supposed to output hello. What makes you think it's supposed to echo hello? That's system specific on what will happen. According to the bash manual, (cat) is evaluated first, and will result in a /dev/fd reference, or a named pipe (it so happens that it is a /dev/fd reference in cygwin). But this pipe is tied to the subprocess, so it only exists as long as the subprocess exists. Then bash does the redirection. If (cat) has already gone away, then the resulting string /dev/fd/63 no longer exists. So redirecting to a non-existent file fails. But if cat hasn't finished executing yet, then the redirection will succeed. Classic data race. Your expectations are wrong, and this is not a bug in cygwin, per se. On the other hand, a named fifo might be more persistent; bash might keep the fifo around until the entire statement is complete, rather than keeping the pipe and /dev/fd reference for the life of the subprocess. But I'd have to recompile bash to force it to use a named fifo, and we already know that named fifos have bugs in cygwin. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Broken process substitution
On 08/13/2010 02:17 PM, Eric Blake wrote: On 08/13/2010 02:04 PM, Daniel Colascione wrote: Try echo hello (cat) -- that's supposed to output hello. What makes you think it's supposed to echo hello? That's system specific on what will happen. According to the bash manual, (cat) is evaluated first, and will result in a /dev/fd reference, or a named pipe (it so happens that it is a /dev/fd reference in cygwin). But this pipe is tied to the subprocess, so it only exists as long as the subprocess exists. Then again, cat should exist until something causes the input side of its pipe to declare EOF; so I guess there's no race in this example after all. Rather, it looks like a limitation in cygwin1.dll. I don't know why bash is unable to duplicate the output end of the pipe to the echo process, unless cygwin's /dev/fd handling doesn't work on pipes. But that's highly likely that you are dealing with yet another one of cygwin's pipe handling shortfalls. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Broken process substitution
On Fri, Aug 13, 2010 at 1:25 PM, Eric Blake ebl...@redhat.com wrote:
Then again, cat should exist until something causes the input side of
its pipe to declare EOF; so I guess there's no race in this example
after all. Rather, it looks like a limitation in cygwin1.dll. I don't
know why bash is unable to duplicate the output end of the pipe to the
echo process, unless cygwin's /dev/fd handling doesn't work on pipes.
But that's highly likely that you are dealing with yet another one of
cygwin's pipe handling shortfalls.
Would these shortfalls also explain why this script doesn't do what
I'd expect (that is, output hello and exit)? It just hangs right now
--- this is the ps output:
I858077407740 63403 4412345 13:41:41 /usr/bin/cygpath
I772477407740 47963 4412345 13:41:41 /usr/bin/cygpath
O173677407740 87963 4412345 13:41:41 /usr/bin/echo
So, err, echo is waiting to output, and cygpath is waiting to receive
input? I don't see why the script shouldn't be making forward
progress.
#!/bin/bash
tmpdir=$(mktemp -dt cygfilter-XX)
stdout_pid=
stderr_pid=
function cleanup() {
[[ -n $stdout_pid ]] /bin/kill $stdout_pid
[[ -n $stderr_pid ]] /bin/kill $stderr_pid
rm -rf $tmpdir
}
trap cleanup 0
mkfifo $tmpdir/f-out
mkfifo $tmpdir/f-err
cygpath -u -f $tmpdir/f-out
stdout_pid=$!
disown %%
cygpath -u -f $tmpdir/f-err 2
stderr_pid=$!
disown %%
$@ $tmpdir/f-out 2$tmpdir/f-err
# Run as cygfilter /bin/echo hello
# ---
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Broken process substitution
On Fri, Aug 13, 2010 at 1:44 PM, Daniel Colascione
dan.colasci...@gmail.com wrote:
On Fri, Aug 13, 2010 at 1:25 PM, Eric Blake ebl...@redhat.com wrote:
Then again, cat should exist until something causes the input side of
its pipe to declare EOF; so I guess there's no race in this example
after all. Rather, it looks like a limitation in cygwin1.dll. I don't
know why bash is unable to duplicate the output end of the pipe to the
echo process, unless cygwin's /dev/fd handling doesn't work on pipes.
But that's highly likely that you are dealing with yet another one of
cygwin's pipe handling shortfalls.
Would these shortfalls also explain why this script doesn't do what
I'd expect (that is, output hello and exit)? It just hangs right now
--- this is the ps output:
Actually, the seemingly-equivalent version below works fine. Maybe
there was a race between the cygpath's starting to read the fifo and
the last line starting to write to it.
The *real* bug seems to be triggered by the following commands:
#!/bin/sh
cd /tmp
mkfifo blah
( echo hello blah )
cat blah
On other systems (OS X and Linux), that just outputs hello, then
both processes exit. On Cygwin, the writer is blocked indefinitely and
has to be SIGKILLed --- even if a reader then starts. And the reader
acts as if there were no writer at all.
#!/bin/bash
set -e
tmpdir=$(mktemp -dt cygfilter-XX)
function cleanup() {
rm -rf $tmpdir
}
trap cleanup 0
mkfifo $tmpdir/f-out
mkfifo $tmpdir/f-err
cygpath -u -f- $tmpdir/f-out
cygpath -u -f- $tmpdir/f-err 2
$@ $tmpdir/f-out 2$tmpdir/f-err
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mode dependent cursor shape lost in cygwin Vim in a Windows console
On 13 August 2010, Andy Koppe wrote: No, but I'm sure a patch implementing the DECSCUSR control sequence using SetConsoleCursorInfo() would be welcome. (Copyright assignment required.) I guess this patch is not in Vim code (which is able to do the job in a normal cmd console window) but rather in cygwin.dll which reconfigures the console. Could you implement such a patch yourself? No emergency, though. Best regards. Jean Johner -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CygWin Security Performance Issues
Christopher Faylor wrote: On Thu, Aug 12, 2010 at 10:17:44PM +0200, DaveLaw wrote: Maybe the co-leader of the project should channel her efforts into just that, rather than getting peoples backs up with unnecessary nitpicking about how she thinks they should structure their emails. Welcome to the cygwin mailing list deny list. Any other takers? Takers as in take him out the back and shoot him? I'd say that's a *bit* mean, even for you... -- Gary Non-kook (allegedly) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: diff /usr/include/endian.orig.h /usr/include/endian.h endian.h.diff
Umm - did you copy straight from glibc's endian.h? That's a no-no; cygwin generally doesn't want to borrow LGPL sources to avoid any licensing questions (borrowing from BSD is okay, on the other hand). You would have to implement things from scratch from a documentation page, or copy from a less-questionable source, rather than using glibc's implementation. I'm stopping right here, so I don't risk tainting myself. How about you instead describe which macros you are missing, so someone can do a clean-room implementation of those macros. After sleep I remembered the error that I posted first, that proves that I did not copy from glibc: + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include byteswap.h If I would have copied from glibc this out-of-order code would be as it must be. And regarding the many (x) I can explain them: I could use any acceptable character, but I chose x for 2 reasons: 1) I, and probably most of you, learned equations at school using x and y, to draw the points along the axes; 2) The x glyph represents the different ways to represent the same number: As a child, I once asked an Unix sysadmin that used a real TTY: -You are telling me that are two different ways to order the 4 bytes of a number. But I can imagine many more ways to represent the same number. For example: 1324 or 1423. ? I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin speed difference on multiple cores -vs- single-core?
Hi Folks, When using cygwin, I've noticed that there seems to be a large speed difference when I boot my windows 7 (32-bit) machine in single-core mode versus the regular number of cores (4, Core i7-930). I've read through the FAQ and didn't notice anything about this issue. Normally, I would expect nearly no speed difference based on the Windows environment... but after some extensive timing tests it seems like the single- core machine is usually at least 2x faster than using the same machine setup in multi-core mode. I limit the number of cores using MSCONFIG, advanced boot options. We have some simple script and more complex scripts which show this behavior. The simple scripts do straightforward things like rm -rf over some directory trees. Even the simple scripts run slowly when the PC is booted with multiple cores. Is this known behavior? Is there some way to work around it so I can boot my PC, use all the cores with other apps, and continue run cygwin 2x faster? Thanks much, andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin speed difference on multiple cores -vs- single-core?
On 8/13/2010 5:37 PM, Andy Nicholas wrote: Hi Folks, When using cygwin, I've noticed that there seems to be a large speed difference when I boot my windows 7 (32-bit) machine in single-core mode versus the regular number of cores (4, Core i7-930). I've read through the FAQ and didn't notice anything about this issue. Normally, I would expect nearly no speed difference based on the Windows environment... but after some extensive timing tests it seems like the single- core machine is usually at least 2x faster than using the same machine setup in multi-core mode. I limit the number of cores using MSCONFIG, advanced boot options. We have some simple script and more complex scripts which show this behavior. The simple scripts do straightforward things like rm -rf over some directory trees. Even the simple scripts run slowly when the PC is booted with multiple cores. Is this known behavior? Is there some way to work around it so I can boot my PC, use all the cores with other apps, and continue run cygwin 2x faster? Several possibilities which you haven't addressed may affect this. Are you comparing the performance of a single thread when locked to a single core, compared to when it is permitted to rotate among cores, with or without HyperThread enabled? I've never run into anyone running win7 32-bit; it may have more such issues than the more common 64-bit. -- Tim Prince -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin speed difference on multiple cores -vs- single-core?
On 8/13/10, Andy Nicholas wrote: Hi Folks, When using cygwin, I've noticed that there seems to be a large speed difference when I boot my windows 7 (32-bit) machine in single-core mode versus the regular number of cores (4, Core i7-930). I've read through the FAQ and didn't notice anything about this issue. Normally, I would expect nearly no speed difference based on the Windows environment... but after some extensive timing tests it seems like the single- core machine is usually at least 2x faster than using the same machine setup in multi-core mode. I limit the number of cores using MSCONFIG, advanced boot options. We have some simple script and more complex scripts which show this behavior. The simple scripts do straightforward things like rm -rf over some directory trees. Even the simple scripts run slowly when the PC is booted with multiple cores. Is this known behavior? Is there some way to work around it so I can boot my PC, use all the cores with other apps, and continue run cygwin 2x faster? Thanks much, andy You want to look at details before concluding anything but if it is real and you blame memory thrashing, I'd be curious to know about it. This is hardly cygwin specific but people here may be interested. Usually memory bottleneck kills you first and more processors can just thrash. At least take a look at task manager and get some idea what may be going on. Off hand it sounds like it may have more to do with the file system details based on test you mention. Disk IO and buffering and syncing can be an issue I would guess. http://archives.free.net.ph/message/20081115.133519.47f76485.el.html http://spectrum.ieee.org/computing/hardware/multicore-is-bad-news-for-supercomputers -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin speed difference on multiple cores -vs- single-core?
Tim Prince n8tm at aol.com writes: Several possibilities which you haven't addressed may affect this. Are you comparing the performance of a single thread when locked to a single core, compared to when it is permitted to rotate among cores, with or without HyperThread enabled? I've never run into anyone running win7 32-bit; it may have more such issues than the more common 64-bit. The scripts we're using form the basis of a build system to invoke GCC and an assembler lots of times throughout a directory tree of a few thousand items. The tree itself on the file-system is not gigantic. I've tried to make sure that the environment has all the usual suspects disabled (virus-checking disabled, paging completely disabled for all disks, nothing else running in the background) before comparing anything. I've been comparing using 2 different methods, one is the time to clean the tree using rm -rf via a makefile on empty directories and the other is to do a full build on a clean tree. When running make we don't use the -j option to use multi-threaded builds. When running each testing method, the CPUs are barely loaded at all (10%, maybe) and there's almost no I/O that registers. Hyperthreading is disabled. I've tried comparisons when configuring the PC using msconfig to present 1 core, 2 cores, and 4 cores. The difference between 1-core and 2 or 4 cores is dramatic with 1-core running 2x+ faster. There's almost no difference in speed between 2 cores and 4 cores. The disk is an SSD. I've recently tried launching the original command-line window with its affinity locked to core0 and priority set to realtime. I've inspected the results using SysInternals' Process Explorer and spawned processes appear to be locked to core0. I made sure that the non-spawned processes like conhost.exe also had their affinities set and their priority raised to realtime. There's no difference in processing speed though. Btw, I don't think the issue is I/O. The disk I'm using is an SSD (OCZ Vertex 2) which is fairly fast. But, the results repeat even if I try a regular 7200 RPM hard drive. Yeah, weird. andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: experimental package: gcc4-4.5.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This package is a test release, owing to regressions with the Ada language, and because it is the first package from a new upstream GCC release series. A full release of GCC-4.5.1 will follow shortly. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- OBTAINING THE RELEASE = 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.exe, fill in all of the options, and make appropriate choices on the Select Packages screen. Because this is an experimental release, any gcc packages you currently have installed will *not* be automatically selected for update to the new version; you will need to select the manually, or use the Exp view of setup's chooser display and disable any other undesired experimental packages. Note also that on next running setup.exe, experimental packages are by default selected for roll-back to the current version; they must be manually deselected in order to retain them. NEWS From the README: (with some minor tweaks added in passing). gcc4-4.5.0-1 - -- This is the first release of the GCC 4 compiler package for Cygwin from the latest upstream GCC release series, version 4.5.0. As with previous Cygwin GCC packages, all the major runtime libraries are implemented as DLLs as well as static archives. It can fully co-exist side-by-side with the older Cygwin gcc-3.4.4 series compiler. All languages are supported, although Ada and Java remain works-in-progress. Because of the regressions in Ada, and in order to give any bedding-in problems from the first release of a new release series, this is a test release. I hope to follow it soon by a full release with Ada working. (... continues ...) WARNING: Experimental release, potential back-compat issues or ABI breaks. == As mentioned above, Ada is known to have regressions. As this is all still experimental, please watch out for bugs. Anything abnormal should be reported, in the first instance, to the main Cygwin mailing list. Cygwin port maintained by: Dave Korn dave.korn.cyg...@gmail.com.use.the.list.please Please address all questions to the Cygwin mailing list at cyg...@cygwin.com This is the key used for signing Cygwin GCC releases: pub 1024D/6A388C3E 2008-05-31 uid Dave Korn (release signing key) dave.korn.cyg...@gmail.com sub 4096g/D4E41590 2008-05-31 Also available at a key-server near you! - - - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (Cygwin) mQGiBEhBdVwRBADGS7UWOR8lvHOcOs161cRjTw1Yp3Qj4Xy5JbaSQFZ6m+DTM7GD y4tPrM1jr6uYGzikdNzYL6tWKUDvVYjs7bwYJXBQ7ryeLJ4LXs+8cmIFIl4uMc8P BEpT67gs1+MchBemr1B/s4V8s9laX81mMYd73qqefuCnbUU8+iBKBzfDhwCg6xQU yIORoWJz5qIHwO23N2uuuKUD/0AsLJOMV1Ig/NVK8ZMss4ozIsgOiBBJ7ZQ9bzzR 8D5EhahVTwPJ7dMXGKWfb21gJHtYjOtwDYJyc5HdIHBPWylI0u6vkiIDD4TZjSDA fIMBgTKp9SjKBtr4ZJzYZUguTFGJFBDLyieyUDWTXBVQSaDASzEjwwdbbKo5/wzY GzvYA/458txhAz1GoB3hnaEJgIK0HaOVjetvZif9QQ1L0x10EIjdwgxN8pMR3Gv8 d+pALJpivIe5eMrU2QLpSbiK5QRkndJBYdiEobLCY3Ca6elRB8/ioKUyOzngtAe9 ny0dUNEWDxwtk2yJSxMrcfRjSJMs+4efCqXrRIkfXr1ibE1JybQ8RGF2ZSBLb3Ju IChyZWxlYXNlIHNpZ25pbmcga2V5KSA8ZGF2ZS5rb3JuLmN5Z3dpbkBnbWFpbC5j b20+iGMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSMUtrgIZAQAK CRBN0oLlajiMPrQTAKCJhzyfI8MKSJjYNTXYCo/GITfvTQCgp2Jw70u5NQojF09f uPhfnX+xed+IYwQTEQIAIwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJIVRdm AhkBAAoJEE3SguVqOIw+l4QAoJSM49UfFNHx3jSTV3+o+TQF9Uo/AKDa5iFeDTuO 10t5Rpng0OWJPTR7N7kEDQRIQXVcEBAAnOffXRQSAPcJKW9z8OXwd0UmNFGZbjb5 CW53i2HYmqiYfMLL6XHyyB2o0e0jZuao/+PgxnoVaqpPh7DXYfjup/u5ll2kAK2I VImGIFYifRLQAWCivQa4LXWR2EvIi1MURrmEjN+JKStBAySiED21QELetUGNzeYT rsWBpHmAibcBAbwFPw0mhFPqvApcrpMJhALehCqPEu/rfeUnziqo8pdpeKkL0ENl GsNONGYhDIjzexclRNFFYwzmK2cS5sxwyH94OxBABfgwxsVYB0+zsdjPk3JybK52 +MIcYQU4NBoCYo184pFJ4QhzKmt/8sAicaxLsU4DHqyy9SwFH1cV1Su5RN3DGG2S 0hFImqyTeCiSW2FDSgOtAF0ImEY3HNkfLgych5nFKRj0itPdFG/t6qCJKLf8JsZP 2QDaLQO+42jwn6Y47PaBEMJGttPaY6guATJqVefqayKI4j22w2le4PLxYJ3fIlqi 5rS5m6mJV2ZFRuqSgmGPDgb8+vnvTG/PCTCcK3j4jzUvJ3bX9FtyV9cFnlF+CfQc ZMdx4qHrhKgoiqJt19Mk8rb19L6KqyLNgJyqvwOcsX8P2yM8t/FAuUeg1EgnYbMz RywEHEa2+rj2R1FPJGtJdOQLgrPgd4m9t5Eq7zFPuJgKNlWHf1Y0M82A37iYnWna DyqON5+pPQ8ABAsP/jOOvQjU79Pd8ph7c2LK+UUjGPQVYO5bwUOCDs9ctSIbQgPh R4l4Ae3Lpgduv7V4ssz15qOGPAe++FmbutyYjF2mxwvwX86coWnkarkhuTrwoB29 Mb9IAqqpWcLqdSzUof5XSm4hesB8PASC5hCJ3D6ztMTX3OOEywSt8LJlOvgaM/YZ fSit+5xVfGG9AXZya+jKjJnJBCyiqdWZslfRLaSHDF4M4roDk2cl8SxVJTMiBl5g
