RE: bash CRLF problems (I have read the recent announcement)
Kevin Layer wrote:
I'm really perplexed by the following behavior:
[EMAIL PROTECTED] ~
$ cat -v foo1.sh
echo 8010 foo1.out
[EMAIL PROTECTED] ~
$ cat -v foo2.sh
sh foo1.sh
version=`cat foo1.out`
echo ${version}.bar foo2.out
cat -v foo2.out
[EMAIL PROTECTED] ~
$ sh foo2.sh
8010^M.bar^M
[EMAIL PROTECTED] ~
$ mount
C:\cygwin\bin on /usr/bin type system (textmode)
C:\cygwin\lib on /usr/lib type system (textmode)
C:\cygwin on / type system (textmode)
c: on /c type system (textmode)
z: on /z type system (textmode)
[EMAIL PROTECTED] ~
$
The (real) scripts involved run on non-Windows platforms, so putting
in `d2u' isn't an option. I'd rather not resort to `tr' either, since
I have a large number of places to fix. Large.
The bug, IMO, is the assigment to version of `cat foo1.out` contains a
^M. I'm on a text mount, so this is counter to what I thought would
happen.
I don't know if this helps you or not, but I get slightly different
output, consistent with what I believe you expected. igncr will indeed
eat the \r from the `cat...` (thanks Eric once again). Unfortunately
you're still left with the trailing \r from the last cat.
[EMAIL PROTECTED]:~% sh foo2.sh
8010.bar^M
[EMAIL PROTECTED]:~% sh --version
GNU bash, version 3.2.5(7)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~% echo $SHELLOPTS
braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:
monitor
But as was recently pointed out on the list, echo -n would suppress the
final \r in your test case.
Dan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: bash CR and backquotes trouble
Nicolas Roche wrote: t=`gcc --print-multi-lib` where gcc is a mingw gcc. As my gcc is a mingw program, it outputs CR/LFs. In previous versions bash used to ignore the CR, so t variable was not containing any CR. Now this is no more the case and this is causing some troubles Looking back to a comment Eric Blake made on 10/23 igncr only ignores \r in the input file, not in `` or $() command substitution. But IFS will cover that. Hmm, maybe I should take a closer look at command substitution to see if I can make igncr affect that as well. I'll try and get that in bash-3.2-4 Then again on 10/24 A new release of bash, 3.2-4, is now available for experimental use, replacing 3.2-3. Version 3.1-9 remains as the current version for now. ... 5. You can also experiment with the IFS variable for controlling how bash will treat \r during variable expansion. So you could give the new experimental version of Bash a try. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Similar Bash 3.1.18 CR/LF Problem
Eric Blake wrote: But I'm not sure whether making igncr the default in 'bash --posix', aka '/bin/sh', is wise, since POSIX does not permit this behavior. My only concern is that by making igncr cognizant of whether posix behavior is requested, people will start asking 'why does my script work with #!/bin/bash but not #!/bin/sh?'. Ugh... If push does come to shove, I guess I can tell the Windows-centric folks on the team to set SHELL=c:/cygwin/bin/bash.exe so that the Win32 Version of GNU make will execute bash c:\temp\tempscript.sh rather than sh. Just one more thing to get wrong; one more thing for our developer install sheet; one more faq; one more... Seriously though, as long as I can get it to work we'll be happy. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: bash-3.1-9
Eric Blake wrote: First, if a script is specified with a DOS path instead of a POSIX path (although this is not the recommended behavior in cygwin), bash will ensure that the underlying mount mode is respected, rather than the default cygwin behavior of using binary mode, allowing the use of DOS paths on text mounts the way 3.1-6 behaved. Eric, as one of the complainers :) thanks. I just wanted to check in and say that our case of executing a cr/lf script via a DOS path on a text mount is working as well as it used to. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Similar Bash 3.1.18 CR/LF Problem
I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. cgf As much as I would love to work in a pure cygwin environment it's not always possible. In our particular case the scripts are generated by the Win32 port of gnu's make. It really wants to put a cr/lf on the end of the shell script it makes and invoke sh passing it the DOS pathname of that script. I'd love to be able to use cygwin's make, but it's just not practical. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Similar Bash 3.1.18 CR/LF Problem
IIRC, Cygwin explicitly treats out-of-mount (Win32) paths as binary. Igor Yes, that's fits my recollection as well. Since both of us recall this, there's no need for anyone to check the source. Two IIRCs means we must be right! ;-) :) That's how my rulebook works too. So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going pure cygwin was an option. Thanks for the insights. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Similar Bash 3.1.18 CR/LF Problem
Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. Mounts are as follows... C:\OE\trunk\rt\binmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Similar Bash 3.1.18 CR/LF Problem
Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. What about bash all variations. Bash fails in exactly the same way that sh does. I was able to get the real output that I should have gotten originally. :) -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 14 03:21 bash.exe -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 28 13:20 sh.exe C:\Tempmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) C:\Tempod -c foo.sh 000 d a t e ; d a t e \r \n 014 C:\Tempod -t x1 foo.sh 000 64 61 74 65 3b 20 64 61 74 65 0d 0a 014 C:\Tempsh foo.sh Thu Sep 28 13:21:46 PDT 2006 Thu Sep 28 13:21:46 PDT 2006 C:\Tempsh c:/Temp/foo.sh Thu Sep 28 13:21:52 PDT 2006 : command not founde 1: date C:\Tempsh c:\Temp\foo.sh Thu Sep 28 13:21:58 PDT 2006 : command not founde 1: date C:\Tempsh /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:07 PDT 2006 Thu Sep 28 13:22:08 PDT 2006 C:\Tempbash foo.sh Thu Sep 28 13:22:12 PDT 2006 Thu Sep 28 13:22:12 PDT 2006 C:\Tempbash c:/Temp/foo.sh Thu Sep 28 13:22:17 PDT 2006 : command not founde 1: date C:\Tempbash c:\Temp\foo.sh Thu Sep 28 13:22:23 PDT 2006 : command not founde 1: date C:\Tempbash /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:36 PDT 2006 Thu Sep 28 13:22:36 PDT 2006 Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. That suggests the postinstall script didn't run for some reason. That was my guess. But since this was the cygwin installer run off of the cygwin site I thought I'd mention it, if for no other reason than tracking purposes. Maybe there's a problem with the installer / postinstall script when downgrading? Or perhaps that's intended behavior. It was just surprising. And... it didn't run again when re-upgrading just bash to the new (broken) version so we had to manually copy bash.exe to sh.exe. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin/X crashes when using -clipboard; Win95; switched fromG nome to KDE on linux
Alexander Gottwald wrote: Jay Smith wrote: Hi Alexander, Yes, I did get crashing from simple cases (i.e. plain text in a basic KDE xterm [konsole]). In a couple cases the crash was within a few seconds and in other cases I was able to do two or three copy/paste operations before it crashed. konsole is different from xterm. konsole most likely uses qt functions for clipboard handling. But i doubt this makes any difference. I am afraid that I haven't a clue how to track this down myself. Does this error message give you any ideas? winClipboardErrorHandler - ERROR: BadValue (integer parameter out of range for operation) No. Unfortunatly not. This error could result from any x11 call in the clipboard thread. I could add more output which at least prints the function called but this will only give minor hints. To find the code where it fails one would have to debug XWin. Does the rest of the log output (in my original post) look correct? Are there any clues there? If this can't be solved, then it may mean that Windows 95 may be no longer supported for Cygwin/X. I haven't been watching this entire thread but there is additional logging code in the sources that I don't think have made it into an official release. Also, I did fix a few bugs that could cause a crash when text was copied from X. Jay, have you tried building your own XWin32 from the CVS sources? If you have, then you could try using -logverbose 3 to get additional clipboard messages. Dan
RE: Pointer bug in multiwindow mode (native window manager)
On June 2 Kris Thielemans wrote: As I already mentioned, occassionally my mouse pointer does not display anymore. This then happens for all open and new X-windows. I believe that this problem has been fixed in the source code but has not made its way into an official build. If possible grab the sources and have a build. There is one known cause of this: XP's remote desktop feature. When you come back to your machine after having a remote desktop session the cursor will disappear. There could be others as well. hth
Tracking Down Disappearing Cursors
After a bit of sleuthing I think I understand why the cursor is disappearing inside X windows after a remote desktop session. Unfortunately I don't understand enough of the motive of the current code in order to suggest a fix. It appears that there is some sort of misunderstanding between wincursor.c and the various window procs. One of the first acts that wincursor.c does is to do a ShowCursor(TRUE) but not set the global variable g_fCursor. The effect is that the cursor is now locked on. The window procs all attempt to hide the hardware cursor while it is in the client area by calling ShowCursor(FALSE) when the mouse enters the client area and then ShowCursor(TRUE) when it leaves, or when the window is deactivated or various other events. But it does this under the control of the afore mentioned g_fCursor variable. I assume that this is to deal with the refcounted nature of the ShowCursor call. Now, when remote desktop comes in, it just resets the global ShowCursor refcount. Both on the remote side and when control is restored to the owning display. This causes the window proc's desire for cursor control to be honored, hiding the cursor when it comes into the client are and then showing the cursor again when it leaves. What's surprising is that a cursor is visible while in the remote desktop, not always the right cursor, but there is one. Only when returning to the main display does the cursor disappear for good. So, what's the right fix? I don't know. I have a guess. If XWin is now really 100% hardware cursor based then we don't need to do any of this cursor wrangling. My guess is that we could even remove all the MouseTrackEvent stuff as well since that only appears to matter to hiding and showing the cursor over the client area. I've given it a whirl and it appears to work ok. My cursor is always visible and the proper shape. Also a surprise is that the cursor is better behaved while running on the remote desktop. It still has problems but it's much better than it was. Unfortunately I put very little strain on X. I run xterm, emacs, and occasionally IntelliJ. I always run XWin directly in multiwindow mode, no startx or .rc file mumbo jumbo here. So I don't feel confident enough to really suggest a real patch, only a course of investigation to those who might have a bit more knowledge or bravery that I. Hope this helps, Dan
RE: XWin.exe 6.7-4 clipboard on Win 2K server sp4 - prevents Wind ows cut/copy
Jesse Burson wrote: I'm using XWin.exe 6.7-4 I am not able to cut or copy from Windows apps. Wait until the next version. Some Windows apps, Remote Desktop for one really mess up the Windows clipboard chain. You can see this using the old clipbrd.exe tool as well. Versions of XWin post -4 have a fix but unfortunately can also die a horrible death. The next version might have both fixed. hth, Dan
XWin/Clipboard/Crash/Hang - Patch Take 2
Harold L Hunt II wrote:
I'm including the small fix from winclipboardwndproc.c in the next
release, but the changes to the debug messages should probably be
done using the newer logging functions that accept a log level and
verb.
I think the small fix got lost. At least I couldn't find it in
the clipboard window proc. No worries it gave me time to look into
the problem some more.
This patch should solve XWin crashing (silently quitting) while
copying or pasting after using another Windows application which
utilizes the clipboard chain. Remote desktop is one such application.
If further crashes occur using XWin -logverbose 3 will be able to generate
hopefully useful information from the clipboard.
ChangeLog:
* winclipboard.h: Add extern prototypes for winDebug, winErrorFVerb
copied from winmsg.h.
* winclipboardinit.c (winFixClipboardChain): Post rather than send the
reinit message to the clipboard window. Sending the message caused,
or possibly just exacerbated an existing, race condition that would
cause the X server to hang when coming back from a remote desktop
session.
* winclipboardwndproc.c (winProcessXEventsTimeout): switch to new
logging api's.
(winClipboardWindowProc): switch to new logging api's. Add some
additional debug logging. Make best effort to prevent our window
appearing twice in the clipboard chain. Also detect loops when they
occur and try to behave in a reasonable way.
Patch:
Index: winclipboard.h
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboard.h,v
retrieving revision 1.1.4.1.2.14
diff -u -p -r1.1.4.1.2.14 winclipboard.h
--- winclipboard.h 23 Apr 2004 18:17:29 - 1.1.4.1.2.14
+++ winclipboard.h 7 May 2004 15:32:27 -
@@ -84,6 +84,8 @@
extern char *display;
extern void ErrorF (const char* /*f*/, ...);
+extern void winDebug (const char *format, ...);
+extern void winErrorFVerb (int verb, const char *format, ...);
/*
Index: winclipboardinit.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboardinit.c,v
retrieving revision 1.1.4.1.2.8
diff -u -p -r1.1.4.1.2.8 winclipboardinit.c
--- winclipboardinit.c 23 Apr 2004 18:17:29 - 1.1.4.1.2.8
+++ winclipboardinit.c 7 May 2004 15:32:27 -
@@ -135,6 +135,6 @@ winFixClipboardChain (void)
if (g_fClipboard
g_hwndClipboard)
{
- SendMessage (g_hwndClipboard, WM_WM_REINIT, 0, 0);
+ PostMessage (g_hwndClipboard, WM_WM_REINIT, 0, 0);
}
}
Index: winclipboardwndproc.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboardwndproc.c,v
retrieving revision 1.1.4.1.2.20
diff -u -p -r1.1.4.1.2.20 winclipboardwndproc.c
--- winclipboardwndproc.c 26 Apr 2004 19:53:49 - 1.1.4.1.2.20
+++ winclipboardwndproc.c 7 May 2004 15:32:27 -
@@ -102,8 +102,8 @@ winProcessXEventsTimeout (HWND hwnd, int
tv); /* No timeout */
if (iReturn = 0)
{
- ErrorF (winProcessXEventsTimeout - Call to select () failed: %d.
- Bailing.\n, iReturn);
+ winErrorFVerb (1, winProcessXEventsTimeout - Call to select ()
+failed: %d. Bailing.\n, iReturn);
break;
}
@@ -145,9 +145,7 @@ winClipboardWindowProc (HWND hwnd, UINT
{
case WM_DESTROY:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_DESTROY\n);
-#endif
+ winDebug (winClipboardWindowProc - WM_DESTROY\n);
/* Remove ourselves from the clipboard chain */
ChangeClipboardChain (hwnd, s_hwndNextViewer);
@@ -161,24 +159,61 @@ winClipboardWindowProc (HWND hwnd, UINT
case WM_CREATE:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_CREATE\n);
-#endif
+ winDebug (winClipboardWindowProc - WM_CREATE\n);
/* Add ourselves to the clipboard viewer chain */
s_hwndNextViewer = SetClipboardViewer (hwnd);
+ if (s_hwndNextViewer == hwnd)
+ {
+ s_hwndNextViewer = NULL;
+ winErrorFVerb (1, winClipboardWindowProc - WM_CREATE:
+ attempted to set next window to ourselves.);
+ }
}
return 0;
case WM_CHANGECBCHAIN:
{
+ static Bool s_fProcessingChangeCBChain = FALSE;
+ winDebug (winClipboardWindowProc - WM_CHANGECBCHAIN: wParam(%x)
+ lParam(%x) s_hwndNextViewer(%x)\n,
+ wParam, lParam, s_hwndNextViewer);
+
+
+ /*
+* We've occasionally seen a loop in the clipboard chain. Break
+* it on the first hint of recursion.
+*/
+ if (! s_fProcessingChangeCBChain)
+ {
+ s_fProcessingChangeCBChain = TRUE;
+ }
+ else
+ {
+ winErrorFVerb (1, winClipboardWindowProc - WM_CHANGECBCHAIN -
+
Debugging Output
Alexander Gottwald wrote: - debugging output: winDebug(format, args...) - non important configuration messages: winErrorFVerb(2, format, args) -logverbose 3...? can give debug messages with differing severity eg -logverbose 3 may print simple traces while -logverbose 10 will also dump all windows messages received Looking at the #if 0'd logging in windclipboardwndproc would you expect that be converted to winDebug (which is logged at level 3) or should it be explicitly logged at level 10: winErrorFVerb(10,...) since it's really logging window messages? Thanks, Dan
RemoteDesktop/Clipboard Crash Patch
Symptom: After coming back from remote desktop session first copy
operation might crash XWin when using -clipboard (maybe
requiring -multiwindow too).
Cause: XWin becomes its own next window in the clipboard chain
after trying to ensure that it is still in the clipboard
chain.
Fix: Don't allow s_hwndNextViewer to get set to hwnd.
Also:Added new -clipboarddebug flag which turns on more
debugging messages from the clipboard manager.
ChangeLog:
2004-05-03 Dan Wilks [EMAIL PROTECTED]
* iniOutput.c (winUseMsg): Add documentation for new -clipboarddebug flag.
* winclipboardwndproc.c: Add reference to new clipboard debug variable.
(winClipboardWindowProc): Change debugging messages from #if 0 to use
new debug flag. Don't try to set the next window in the clipboard
chain to ourself.
* winglobals.c: Add new g_fClipboardDebug for clipboard debugging.
* winprocarg.c (ddxProcessArgument): Process -clipboarddebug and turn
on g_fClipboardDebug.
Diffs:
Index: InitOutput.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/InitOutput.c,v
retrieving revision 1.1.4.1.2.39
diff -u -p -r1.1.4.1.2.39 InitOutput.c
--- InitOutput.c26 Apr 2004 12:50:59 - 1.1.4.1.2.39
+++ InitOutput.c3 May 2004 22:51:50 -
@@ -385,6 +385,10 @@ winUseMsg (void)
\tRun the clipboard integration module.\n
\tDo not use at the same time as 'xwinclip'.\n);
+ ErrorF (-clipboarddebug\n
+ \tRun the clipboard integration module with debugging output.\n
+ \tDo not use at the same time as 'xwinclip'.\n);
+
ErrorF (-nounicodeclipboard\n
\tDo not use Unicode clipboard even if NT-based platform.\n);
#endif
Index: winclipboardwndproc.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xwin/winclipboardwndproc.c,v
retrieving revision 1.1.4.1.2.20
diff -u -p -r1.1.4.1.2.20 winclipboardwndproc.c
--- winclipboardwndproc.c 26 Apr 2004 19:53:49 - 1.1.4.1.2.20
+++ winclipboardwndproc.c 3 May 2004 22:51:50 -
@@ -44,6 +44,7 @@
*/
extern Boolg_fUnicodeSupport;
+extern Boolg_fClipboardDebug;
extern void*g_pClipboardDisplay;
extern Window g_iClipboardWindow;
extern Atomg_atomLastOwnedSelection;
@@ -145,9 +146,10 @@ winClipboardWindowProc (HWND hwnd, UINT
{
case WM_DESTROY:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_DESTROY\n);
-#endif
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_DESTROY\n);
+ }
/* Remove ourselves from the clipboard chain */
ChangeClipboardChain (hwnd, s_hwndNextViewer);
@@ -161,18 +163,27 @@ winClipboardWindowProc (HWND hwnd, UINT
case WM_CREATE:
{
-#if 0
- ErrorF (winClipboardWindowProc - WM_CREATE\n);
-#endif
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_CREATE\n);
+ }
/* Add ourselves to the clipboard viewer chain */
s_hwndNextViewer = SetClipboardViewer (hwnd);
+ if (s_hwndNextViewer == hwnd)
+ {
+ s_hwndNextViewer = NULL;
+ }
}
return 0;
case WM_CHANGECBCHAIN:
{
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_CHANGECBCHAIN: wParam(%x)
s_hwndNextViewer(%x)\n, wParam, s_hwndNextViewer);
+ }
if ((HWND) wParam == s_hwndNextViewer)
s_hwndNextViewer = (HWND) lParam;
else if (s_hwndNextViewer)
@@ -197,10 +208,22 @@ winClipboardWindowProc (HWND hwnd, UINT
*/
s_fCBCInitialized = FALSE;
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_WM_REINIT: Removing
ourselves\n);
+ }
ChangeClipboardChain (hwnd, s_hwndNextViewer);
s_hwndNextViewer = NULL;
s_fCBCInitialized = FALSE;
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_WM_REINIT: Readding
ourselves\n);
+ }
s_hwndNextViewer = SetClipboardViewer (hwnd);
+ if (s_hwndNextViewer == hwnd)
+ {
+ s_hwndNextViewer = NULL;
+ }
}
return 0;
@@ -211,9 +234,20 @@ winClipboardWindowProc (HWND hwnd, UINT
Window iWindow = g_iClipboardWindow;
int iReturn;
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_DRAWCLIPBOARD\n);
+ }
+
/* Pass the message on the next window in the clipboard viewer chain
*/
- if (s_hwndNextViewer)
- SendMessage (s_hwndNextViewer, message, 0, 0);
+ if (s_hwndNextViewer)
+ {
+ if (g_fClipboardDebug)
+ {
+ ErrorF (winClipboardWindowProc - WM_DRAWCLIPBOARD:
Forwarding message
Remote Desktop, MultiWindow Cursors
Looks like the newer versions of XWin are having cursor problems when coming out of remote desktop (XP Pro). After a remote desktop session the cursor completely disappears in the X window client area. Here's what I'm seeing: - Run a cygwin bash shell - XWin -multiwindow -clipboard - Run xterm on a Linux box w/ PuTTY tunneling X. - Move the cursor around the xterm. Nice I-Beam. - Go to another machine, remote desktop in. - xterm is still active app but cursor is now outside the xterm window over the windows desktop but with X's X cursor. - Move cursor around. It remains the X cursor wherever you move it. Verify. - Activate a Windows app (IE) and then back to xterm. Cursor returns to I-Beam and proper behavior. - Shut down remote desktop. Return to tty. - Now when the mouse moves over any X window it completely disappears. Also, at this point, copying anything will completely crash XWin. I'm in the process of looking into it. My debug build of current sources doesn't exhibit this behavior. I'll try a non-debug build next. Hey, is there a safe, automated, way to do a full, clean build of just Xserver? Dan
Fix - Occasional Paste Problem
I've just recently started using Cygwin/X but occasionally paste from Win32
to X fails. I'm using -multiwindow and -clipboard. I tracked down one
source of the failures: XP's remote desktop. Remote desktop does not
properly restore the clipboard chain when it shuts down. Result is that
XWin no longer sees clipboard messages when you copy in a Win32 app.
The fix is rather simple although a bit forceful. Just reinitialize the
clipboard chain each time the app is activated or deactivated - on each
WM_ACTIVATEAPP message.
Here's a proposed patch. Sorry, not from CVS since I can't get external cvs
access from work at the moment. They are from the most recent install from
cygwin.com though (6.7.0.0-7).
If not obvious this is the first time I've sent in a patch so please let me
know if there's anything you'd like done differently (other than using the
CVS sources - sorry).
Dan
ChangeLog
2004-04-21 Dan Wilks [EMAIL PROTECTED]
* win.h: Add prototype for winFixClipboardChain
* winclipboard.h: Add definition WM_WM_REINIT a private windows message that
the clipboard window uses to reinitialize the clipboard viewer chain.
* winwndproc.c (winWindowProc): Call winFixClipboardChain on application
activation/deactivation to ensure that XWin is still in the clipboard chain.
* winclipboardinit.c: Added references to g_fClipboard and g_hwndClipboard
for winFixClipboardChain to use.
(winFixClipboardChain): New function. Ensures that XWin is still in the
Windows clipboard chain if we're using the internal clipboard.
* winclipboardwndproc.c (winClipboardWindowProc): Process WM_WM_REINIT and
force ourselves back into the clipboard chain.
Patches
--- win.h.save 2004-04-09 23:12:32.00100 -0700
+++ win.h 2004-04-21 16:44:29.421875000 -0700
@@ -756,6 +756,9 @@ winPixmapToRegionNativeGDI (PixmapPtr pP
Bool
winInitClipboard (void);
+
+void
+winFixClipboardChain (void);
#endif
--- winclipboard.h.save 2004-03-30 07:00:09.00100 -0800
+++ winclipboard.h 2004-04-21 16:25:57.140625000 -0700
@@ -76,6 +76,7 @@
#define WIN_XEVENTS_CONVERT2
#define WIN_XEVENTS_NOTIFY 3
+#define WM_WM_REINIT (WM_USER + 1)
/*
* References to external symbols
--- winwndproc.c.save 2004-04-03 12:36:33.00100 -0800
+++ winwndproc.c2004-04-21 16:47:18.65625 -0700
@@ -1110,6 +1110,9 @@ winWindowProc (HWND hwnd, UINT message,
ShowCursor (TRUE);
}
+ /* Make sure the clipboard chain is ok. */
+ winFixClipboardChain ();
+
/* Call engine specific screen activation/deactivation function */
(*s_pScreenPriv-pwinActivateApp) (s_pScreen);
return 0;
--- winclipboardinit.c.save 2004-03-26 11:43:15.00100 -0800
+++ winclipboardinit.c 2004-04-21 16:56:35.453125000 -0700
@@ -47,6 +47,8 @@ DISPATCH_PROC(winProcSetSelectionOwner);
extern pthread_t g_ptClipboardProc;
extern winDispatchProcPtr winProcSetSelectionOwnerOrig;
+extern Boolg_fClipboard;
+extern HWNDg_hwndClipboard;
/*
@@ -126,3 +128,13 @@ winClipboardCreateMessagingWindow ()
return hwnd;
}
+
+void
+winFixClipboardChain (void)
+{
+ if (g_fClipboard
+g_hwndClipboard)
+ {
+ SendMessage (g_hwndClipboard, WM_WM_REINIT, 0, 0);
+ }
+}
--- winclipboardwndproc.c.save 2004-03-30 06:56:01.00100 -0800
+++ winclipboardwndproc.c 2004-04-21 17:08:17.15625 -0700
@@ -181,6 +181,32 @@ winClipboardWindowProc (HWND hwnd, UINT
}
return 0;
+case WM_WM_REINIT:
+ {
+/* Ensure that we're in the clipboard chain. Some apps,
+ WinXP's remote desktop for one, don't play nice with
+ the chain. This message is called whenever we receive
+ a WM_ACTIVATEAPP message to ensure that we continue to
+ receive clipboard messages.
+
+ It might be possible to detect if we're still in the
+ chain by calling
+ SendMessage (GetClipboardViewer(), WM_DRAWCLIPBOARD, 0, 0);
+ and then seeing if we get the WM_DRAWCLIPBOARD message.
+ That, however, might be more expensive than just putting
+ ourselves back into the chain.
+*/
+
+s_fCBCInitialized = FALSE;
+ChangeClipboardChain (hwnd, s_hwndNextViewer);
+s_hwndNextViewer = NULL;
+s_fCBCInitialized = FALSE;
+s_hwndNextViewer = SetClipboardViewer (hwnd);
+ }
+ return 0;
+
case WM_DRAWCLIPBOARD:
{
Initial Comments From a Noob
Noob alertHey all/Noob alert With that out of the way... Last Friday (4/15/04) I updated my Cygwin tools (longtime user) and installed (for the first time) all the Cygwin/X servers apps (setup/x11-base 6.7.0.0-7, cygcheck XFree86-xserv 4.3.0-68). I got up and running over a PuTTY-supplied ssh tunnel without too much grief (I'll deal with a Cygwin tunnel later). I'm running XWin.exe with -multiwindow -clipboard. Here's a list, roughly in descending order of pain, of the things I've run into in the past day or so. Some are already on to do lists but they're here again just for ranking's sake. - The amount of effort y'all have put into this project is amazing. Great job. - Paste Win - X: Today I copied a command-line from a Word doc, or perhaps a web page and tried to paste it into my xterm. The only thing pasting into X was something I had copied from another xterm earlier. Even now, even though I can paste Win32 copied text into Notepad it won't paste into xterm or emacs. I know that copy/paste worked in both directions when I first started up the X server. I've had this same thing happen with Exceed and XWin32. Maybe with a bit more active and accessible development effort we can make this more reliable. - Ctrl-Shift-Tab: What can I say, I'm too used to Windows. I use emacs w/ cua.el and added ctrl-tab/ctrl-shift-tab bindings to cycle through the buffer list. I can't say for sure if this was working on Friday or not, but today it doesn't do anything. (global-set-key [(C-S-kp-tab)] (lambda () (interactive) (crs-bury-buffer -1))) - Desktop resize: When I remote desktop into my computer and the screen size changes the background window isn't resizing yet. I saw that the first bit of code is in an #if 0 state. I'm looking forward to the implementation. - Windows Cursor: At the moment the Windows cursor isn't being hidden while its over the x window client area. This just started this morning when I came back from the weekend. Could be some sort of artifact from remote desktop use? Anyway there's quite an art to ignoring the Windows cursor especially when it isn't a simple arrow (window resize arrow for instance). - Popup windows(?): Using the IntelliJ IDEA I can press Alt+F to bring up the file menu. Let go of the Alt key, then press Alt-Tab to switch to another window. If it's another X window, the file menu eventually goes away. If it's a Windows window (this message in Outlook for example) the file menu never goes away. - X Tooltips (not sure what they're called in x) can popup over non X windows. For example, open emacs and then switch to a non-x app like Outlook. From time to time it appears as if XWin hasn't released mouse capture and the tooltips from emacs (icon bar, status bar, ...) will pop up over the non-x application. - Painting: If you click in the title bar of an xterm buried behind another one and drag the window, the contents of the top window are dragged around until the window gets a chance to be repainted. Also this morning when bringing up hidden xterms the xterm window was painted with the contents of the hidden root window before the underlying xwindow(?) had been brought to the foreground. Neither of these are problems just entertaining to watch. Dan
