[ITP] xclip 0.12
xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections (the clipboard) from the command line. It can read data from standard in or a file and place it in an X selection for pasting into other X applications. xclip can also print an X selection to standard out, which can then be redirected to a file or another program. xclip is included in the Debian distribution: http://packages.debian.org/stable/xclip http://zfire.free.fr/cygwin/xclip-0.12-1.tar.bz2 http://zfire.free.fr/cygwin/xclip-0.12-1-src.tar.bz2 setup.hint - category: X11 requires: libXmu6 libX11_6 sdesc: Command line clipboard grabber ldesc: xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections (the clipboard) from the command line. It can read data from standard in or a file and place it in an X selection for pasting into other X applications. xclip can also print an X selection to standard out, which can then be redirected to a file or another program.
Re: selection to clipboard in xterm
Thanks to your Reply, Jim. Yes, I tried SHIFT+INSERT (which I know from XEmacs) to paste, but I never get pasted into a windows application what I highlighted in my xterm earlier on. Nevertheless, from one xterm to another xterm this works fine... One additional remark: When I highlight a piece of text in my xterm, the content of the windows clipboard does not remain unaffected: it is cleared (reset to the empty string). Even harder for me to understand ;- ... Greetings, Sven Jim Reisert wrote: Have you tried SHIFT+INSERT to paste text into those windows? -- Mit freundlichen Grüßen Dipl. Inform. Sven Severus Softwareentwicklung -- HIMA Paul Hildebrandt GmbH + CO KG Abt: Entwicklung Software Albert-Bassermann-Strasse 28 68782 Bruehl Germany Tel: +49 6202 709-289 Fax: +49 6202 709-299 E-Mail: s.seve...@hima.com Internet: www.hima.de -- 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: XWin crash after the launch of startkde on a remote Red Hat 5 machine
Thank you for your comments, I really want to help you on this part of
the X server.
I will now do :
1/ Adapt the patch to be cygwin Xorg compatible
1/ Split the patch into two separate patches
2/ Publish as soon as possible a new patches version which will take
into account your comments :
*a) WM_DESTROYCLIPBOARD message (Could you be a little more precise
concerning this, I'm not sure to realy understand the issue
*b) Adding a rate-limit on clipboard_generation with a static
variable for example ? and a restart delay (500 Milliseconds should be
enough isn't it ?)
*c) Change the comment about ProcEstablishConnection wrapper and inInitClipboard
*d) Merge the cleanup and the restart function into one
*e) Concerning the use of pthread_cleanup_pop at winClipboardProc end,
do you mean : Replace all pthread_exit() call's by a goto error_exit
label which will call pthread_cleanup_pop(1) (The parameter 1 means
that we have to execute it)
*f) Delete the unnecessary whitespace changes
*g) Concerning the winClipboardErrorHandler tricks, This is for the
situation you said : Window has been deleted by someone else, but we
are still connected to the server I will add a comment in the sources
Michel Hummel
2010/9/28 Jon TURNEY jon.tur...@dronecode.org.uk:
On 24/09/2010 09:15, Michel Hummel wrote:
Hi Jon,
Firstly, thanks very much for looking at this.
You will find attached to this Email a patch (for the git version)
which implements for the clipboard thread :
- Auto cleanup function
- Auto restart function for unexpected exit of the clipboard or
Xerror detection
- Deletion of XQuery wrapper (not needed anymore)
- Deletion of all the xdmcp related tricks (not needed anymore)
For purposes of review it would be easier to split this patch into two
separate patches, (i) the clipboard thread changes and (ii) removing the
unneeded xdmcp tricks.
One thing, this patch deletes the call to EmptyClipboard () in the
winProcSetSelectionOwner function of the winclipboardwrappers.c file
when an owned to not owned transition has been detected. I don't
know why but it was freezing the server for 1 or 2 seconds during
clipboard's restart in xdmcp connection.
Hmmm... I wonder if that's something to do with how we process the
WM_DESTROYCLIPBOARD message? In any case, this should not be happening.
It would be fine if you could tell me, when you think this patch and
the previous one ( which makes the reset of the server working
correctly with clipboard) will be included to the official X server?
We don't have a regular release cycle for the cygwin X server, so I can't
answer that question accurately.
I shall put your previous patch into the next release and assuming it works
well, be pushing it upstream sometime before xserver 1.10
I think this patch needs a little more work.
I'm still a little concerned that there is no rate-limiting on the clipboard
restart mechanism, so in a pathological case (e.g. where some unanticipated
error causes the clipboard to constantly get disconnected), this will spin
using all available CPU.
Some detailed comments below.
---
/home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/InitInput.c
2010-08-18 22:10:54.0 +0200
+++ hw/xwin/InitInput.c 2010-09-17 17:03:08.611244200 +0200
@@ -127,12 +127,6 @@ InitInput (int argc, char *argv[])
winProcEstablishConnectionOrig = InitialVector[2];
InitialVector[2] = winProcEstablishConnection;
}
- if (g_fXdmcpEnabled
- ProcVector[X_QueryTree] != winProcQueryTree)
- {
- winProcQueryTreeOrig = ProcVector[X_QueryTree];
- ProcVector[X_QueryTree] = winProcQueryTree;
- }
#endif
g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE);
---
/home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin//winclipboardthread.c
2010-08-18 22:10:54.0 +0200
+++ hw/xwin/winclipboardthread.c 2010-09-24 16:48:20.689125100
+0200
@@ -48,6 +48,8 @@
extern Bool g_fUnicodeClipboard;
extern unsigned long serverGeneration;
extern Bool g_fClipboardStarted;
+extern Bool g_fClipboardLaunched;
+extern Bool g_fClipboard;
extern HWND g_hwndClipboard;
extern void *g_pClipboardDisplay;
extern Window g_iClipboardWindow;
@@ -72,8 +74,113 @@ winClipboardErrorHandler (Display *pDisp
static int
winClipboardIOErrorHandler (Display *pDisplay);
+static void
+restartClipboardThread(void *pvNotUsed);
+
+static void
+winClipboardCleanup(void *vfdMessageQueue);
+
/*
+ * restartClipboardThread activate the ProcEstablishConnection wrapper
which will start
+ * the thread after next client connection
+ */
This comment doesn't appear to be correct. winInitClipboard() starts the
thread itself.
It looks like this could fight with the ProcEstablishConnection wrapper,
which will call winInitClipboard() once for each
No scrollbar with MSC Mentat
I am using cygwin 1.7.7 to get connectted to a local server (x86_64) running RHE5: $ ssh -X myserver (same issue with -Y) Then I launch a finite-element pre-processor called MSC Mentat: $ mentat2007r1 With this piece of software, the scrollbars are displayed for a very tiny time (0.1 seconds maybe) and disappear. When using the X server of the server (using vncserver for example and a vncviewer), the scrollbars appear normally. Cygwin 1.5 did the same. Regards, Frédéric Bron -- 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: XWin crash after the launch of startkde on a remote Red Hat 5 machine
You will find attached to this Email the modifications you asked.
The X server doesn't freeze anymore when clipboard restarts on xdmcp,
certainly fixed by the cygwin patches.
I added a rate-limit of clipboard_generation which disables restart after
XWIN_CLIPBOARD_RETRIES retries (defined to 40 in winclipboard.h)
and a sleep(XWIN_CLIPBOARD_DELAY) before retries (defined to 1 in
winclipboard.h)
I hope you will like this new version,
Thank you
Michel Hummel
2010/9/29 Michel Hummel hummel.mic...@gmail.com:
Thank you for your comments, I really want to help you on this part of
the X server.
I will now do :
1/ Adapt the patch to be cygwin Xorg compatible
1/ Split the patch into two separate patches
2/ Publish as soon as possible a new patches version which will take
into account your comments :
*a) WM_DESTROYCLIPBOARD message (Could you be a little more precise
concerning this, I'm not sure to realy understand the issue
*b) Adding a rate-limit on clipboard_generation with a static
variable for example ? and a restart delay (500 Milliseconds should be
enough isn't it ?)
*c) Change the comment about ProcEstablishConnection wrapper and
inInitClipboard
*d) Merge the cleanup and the restart function into one
*e) Concerning the use of pthread_cleanup_pop at winClipboardProc end,
do you mean : Replace all pthread_exit() call's by a goto error_exit
label which will call pthread_cleanup_pop(1) (The parameter 1 means
that we have to execute it)
*f) Delete the unnecessary whitespace changes
*g) Concerning the winClipboardErrorHandler tricks, This is for the
situation you said : Window has been deleted by someone else, but we
are still connected to the server I will add a comment in the sources
Michel Hummel
2010/9/28 Jon TURNEY jon.tur...@dronecode.org.uk:
On 24/09/2010 09:15, Michel Hummel wrote:
Hi Jon,
Firstly, thanks very much for looking at this.
You will find attached to this Email a patch (for the git version)
which implements for the clipboard thread :
- Auto cleanup function
- Auto restart function for unexpected exit of the clipboard or
Xerror detection
- Deletion of XQuery wrapper (not needed anymore)
- Deletion of all the xdmcp related tricks (not needed anymore)
For purposes of review it would be easier to split this patch into two
separate patches, (i) the clipboard thread changes and (ii) removing the
unneeded xdmcp tricks.
One thing, this patch deletes the call to EmptyClipboard () in the
winProcSetSelectionOwner function of the winclipboardwrappers.c file
when an owned to not owned transition has been detected. I don't
know why but it was freezing the server for 1 or 2 seconds during
clipboard's restart in xdmcp connection.
Hmmm... I wonder if that's something to do with how we process the
WM_DESTROYCLIPBOARD message? In any case, this should not be happening.
It would be fine if you could tell me, when you think this patch and
the previous one ( which makes the reset of the server working
correctly with clipboard) will be included to the official X server?
We don't have a regular release cycle for the cygwin X server, so I can't
answer that question accurately.
I shall put your previous patch into the next release and assuming it works
well, be pushing it upstream sometime before xserver 1.10
I think this patch needs a little more work.
I'm still a little concerned that there is no rate-limiting on the clipboard
restart mechanism, so in a pathological case (e.g. where some unanticipated
error causes the clipboard to constantly get disconnected), this will spin
using all available CPU.
Some detailed comments below.
---
/home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/InitInput.c
2010-08-18 22:10:54.0 +0200
+++ hw/xwin/InitInput.c 2010-09-17 17:03:08.611244200 +0200
@@ -127,12 +127,6 @@ InitInput (int argc, char *argv[])
winProcEstablishConnectionOrig = InitialVector[2];
InitialVector[2] = winProcEstablishConnection;
}
- if (g_fXdmcpEnabled
- ProcVector[X_QueryTree] != winProcQueryTree)
- {
- winProcQueryTreeOrig = ProcVector[X_QueryTree];
- ProcVector[X_QueryTree] = winProcQueryTree;
- }
#endif
g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE);
---
/home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin//winclipboardthread.c
2010-08-18 22:10:54.0 +0200
+++ hw/xwin/winclipboardthread.c 2010-09-24 16:48:20.689125100
+0200
@@ -48,6 +48,8 @@
extern Bool g_fUnicodeClipboard;
extern unsigned long serverGeneration;
extern Bool g_fClipboardStarted;
+extern Bool g_fClipboardLaunched;
+extern Bool g_fClipboard;
extern HWND g_hwndClipboard;
extern void *g_pClipboardDisplay;
extern Window g_iClipboardWindow;
@@ -72,8 +74,113 @@ winClipboardErrorHandler (Display *pDisp
static int
XWin crashes with DirectX apps
I am seeing a 100% reproducible crash in XWin from xorg-server-1.8.2-1.
I first saw it when I ran a full-screen DirectX game while the server
was running, but I'm also able to reproduce it with the dxdiag tool.
Here are the steps:
1) Start the X server. The exact method of starting it hasn't had any
affect on my testing. Starting either with the installed Start menu
shortcut or just running XWin.exe without arguments produces the same
results.
2) In Start - Run..., enter dxdiag to run the DirectX Diagnostic tool.
3) In dxdiag, select the Display tab.
4) Click the button labeled Test Direct3D (the button labeled Test
DirectDraw also triggers the crash, but takes longer).
XWin crashes when the first full-screen test begins.
I rebuilt the X server with debugging enabled and got the following
backtrace:
$ gdb hw/xwin/XWin.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) run
Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe
[New thread 3084.0xc20]
[New thread 3084.0xda8]
warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at
76d31000
[New thread 3084.0xa68]
[New thread 3084.0xd38]
Program received signal SIGSEGV, Segmentation fault.
0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560
560 IDirectDrawSurface4_SetClipper (pScreenPriv-pddsPrimary4,
(gdb) bt
#0 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560
#1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d0, width=640,
height=480,
mmWidth=3435973836, mmHeight=1080233164)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191
#2 0x0041a369 in winWindowProc (hwnd=0x1c023c, message=126, wParam=16,
lParam=31457920)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344
#3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll
#4 0x001c023c in ?? ()
#5 0x007e in ?? ()
#6 0x0010 in ?? ()
#7 0x01e00280 in ?? ()
#8 0x00419bcc in winReshapeRootless ()
#9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll
#10 0x00419bcc in winReshapeRootless ()
#11 0x7e428ea0 in USER32!DefWindowProcW () from
/cygdrive/c/WINDOWS/system32/user32.dll
#12 0x in ?? ()
(gdb) p pScreenPriv-pddsPrimary4
$1 = (LPDIRECTDRAWSURFACE4) 0x0
(gdb)
Using the option -engine 2 also crashes, but produces a slightly
different backtrace:
(gdb) run -engine 2
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe
-engine 2
[New thread 2208.0x904]
[New thread 2208.0x664]
warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at
76d31000
[New thread 2208.0x350]
[New thread 2208.0x39c]
Program received signal SIGSEGV, Segmentation fault.
0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528
528 IDirectDrawSurface2_SetClipper (pScreenPriv-pddsPrimary,
(gdb) bt
#0 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528
#1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d8, width=640,
height=480,
mmWidth=3435973836, mmHeight=1080233164)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191
#2 0x0041a369 in winWindowProc (hwnd=0x6b00f2, message=126, wParam=16,
lParam=31457920)
at
/usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344
#3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll
#4 0x006b00f2 in ?? ()
#5 0x007e in ?? ()
#6 0x0010 in ?? ()
#7 0x01e00280 in ?? ()
#8 0x00419bcc in winReshapeRootless ()
#9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll
#10 0x00419bcc in winReshapeRootless ()
#11 0x7e428ea0 in USER32!DefWindowProcW () from
/cygdrive/c/WINDOWS/system32/user32.dll
#12 0x in ?? ()
(gdb) p pScreenPriv-pddsPrimary
$2 = (LPDIRECTDRAWSURFACE2) 0x0
(gdb)
It looks like these are both the result of some bad code copied and
pasted in winshaddd.c and winshadddnl.c. From winshadddnl.c, in
winFreeFBShadowDDNL:
/* Detach the clipper from the primary surface and release the clipper. */
if (pScreenPriv-pddcPrimary)
{
/* Detach the clipper */
IDirectDrawSurface4_SetClipper
Re: XWin crashes with DirectX apps
On 29/09/2010 17:49, Kevin Goodsell wrote: I am seeing a 100% reproducible crash in XWin from xorg-server-1.8.2-1. I first saw it when I ran a full-screen DirectX game while the server was running, but I'm also able to reproduce it with the dxdiag tool. Here are the steps: 1) Start the X server. The exact method of starting it hasn't had any affect on my testing. Starting either with the installed Start menu shortcut or just running XWin.exe without arguments produces the same results. 2) In Start - Run..., enter dxdiag to run the DirectX Diagnostic tool. 3) In dxdiag, select the Display tab. 4) Click the button labeled Test Direct3D (the button labeled Test DirectDraw also triggers the crash, but takes longer). XWin crashes when the first full-screen test begins. I rebuilt the X server with debugging enabled and got the following backtrace: Thanks for the detailed problem report. Since I've recently fixed a few crash bugs in this area, introduced with the new -resize functionality, you might like to test the latest snapshot [1] to see if you still have this problem, the source is available at [2]. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 [2] http://cgit.freedesktop.org/~jturney/xserver/log/?h=snapshot $ gdb hw/xwin/XWin.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) run Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe [New thread 3084.0xc20] [New thread 3084.0xda8] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 3084.0xa68] [New thread 3084.0xd38] Program received signal SIGSEGV, Segmentation fault. 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 560 IDirectDrawSurface4_SetClipper (pScreenPriv-pddsPrimary4, (gdb) bt #0 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d0, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 #2 0x0041a369 in winWindowProc (hwnd=0x1c023c, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #4 0x001c023c in ?? () #5 0x007e in ?? () #6 0x0010 in ?? () #7 0x01e00280 in ?? () #8 0x00419bcc in winReshapeRootless () #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #10 0x00419bcc in winReshapeRootless () #11 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #12 0x in ?? () (gdb) p pScreenPriv-pddsPrimary4 $1 = (LPDIRECTDRAWSURFACE4) 0x0 (gdb) Using the option -engine 2 also crashes, but produces a slightly different backtrace: (gdb) run -engine 2 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe -engine 2 [New thread 2208.0x904] [New thread 2208.0x664] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 2208.0x350] [New thread 2208.0x39c] Program received signal SIGSEGV, Segmentation fault. 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 528 IDirectDrawSurface2_SetClipper (pScreenPriv-pddsPrimary, (gdb) bt #0 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d8, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 #2 0x0041a369 in winWindowProc (hwnd=0x6b00f2, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #4 0x006b00f2 in ?? () #5 0x007e in ?? () #6 0x0010 in ?? () #7 0x01e00280 in ?? () #8 0x00419bcc in winReshapeRootless () #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #10 0x00419bcc in winReshapeRootless () #11 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #12 0x in ?? () (gdb) p pScreenPriv-pddsPrimary $2 =
winsup/cygwin ChangeLog fhandler_tty.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-09-29 15:08:49 Modified files: cygwin : ChangeLog fhandler_tty.cc Log message: * fhandler_tty.cc (fhandler_tty_slave::init): Revert to using tc-setpgid since previous change broke some use cases. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5066r2=1.5067 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_tty.cc.diff?cvsroot=uberbaumr1=1.209r2=1.210
Re: [ANNOUNCEMENT] Testing: mintty-0.9b2-1
On 28 September 2010 14:27, Ryan Johnson wrote: On 9/28/2010 2:05 PM, Andy Koppe wrote: On 27 September 2010 17:02, Ryan Johnson wrote: FYI, it looks like you can enable extended mouse mode manually (echo -ne '\e[?1005h'), and it persists across normal mouse mode sessions. Does xterm do that differently? In that case I should change it. I don't know. I submitted two patches, one of which resets extended mode every time the mouse mode changes. Thomas didn't tell me which one he ended up using. Looking at the xterm sources again, Thomas went for the one without the reset. Phew. Emacs has got support for that already? I'm positively surprised by that given the feature only went into xterm a month ago. (Well done for getting your patch into xterm, btw.) Not quite :) Emacs-23 treats all input as utf-8, so xterm's default mouse mode confuses it horribly by producing things that look like (in)valid utf-8. Any x-coordinate 95 looks like the start of a multi-byte sequence which consumes the y, and y coordinates 95 consume whatever character comes after the mouse click, hanging until such a character arrives. The worst part is that it's unpredictable whether emacs will get confused enough to just emit both characters, so there's no reliable way to reprocess the input to fix the problem (I tried...). If xterm emits utf-8, emacs-23 suddenly just works. Emacs-22 needs a small change to xt-mouse.el in order to convert the utf-8 sequences manually, but that's not hard at all if you know they're coming. I can't see a buffer wider than 223 columns being particularly useful, so I guess the main use is with split windows? Exactly. Also, the emacs-23 utf-8 broken-ness kicks in at 95 columns, which is a reasonable size even for one buffer. That's actually what prompted the patch -- stray mouse clicks tended to dump random strings like M#äé into my code at arbitrary places, leading to frequent compile errors. (b) it works around gnu screen intercepting and ignoring the escape sequence I suppose that's useful at sizes95 already then? Screen filters out the \e[?1005h sequence (and other unknown sequences, plus several known ones like the OSI sequences). This makes it impossible to activate extended mouse mode if, e.g., you run emacs inside screen. Screen also rewrites redundant sequences like \e[?1000h\e[?1000h to their minimal equivalent, so I couldn't even use a port knocking approach to get around it. However, mintty lets you activate ext mouse mode before attaching screen, which works nicely around the problem. Given that screen's last release was about 4 years ago, this seems like a Good Thing to me... (Ironically, I think it was some old version of screen which did the utf-8 encoding trick years ago and inspired my patch. I have a six year old .emacs from an hpux machine which had reverse-engineered the encoding without even knowing it was utf-8). Thanks very much for explaining all that. 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: mintty window won't open
On 2010-09-29 07:51 , Andy Koppe wrote: On 28 September 2010 14:38, Jon TURNEY wrote: On 28/09/2010 13:18, Andy Koppe wrote: On 28 September 2010 11:31, Ryan Johnson wrote: I switched from rxvt to mintty yesterday, and it worked great all day. However, today when I try to open a new mintty window from within an existing one, nothing happens. The process starts, but no window appears. This happens when attempting to open both 0.8.3 and 0.9b2 windows from a 0.9b2 window. The broken window also does the same thing to tkdiff but is able to run xterm without problems. Oddly, using the shortcut from the start menu (0.8.3) still works, and any windows I fire up from it (including 0.9b2) work fine after that and can in turn fire up their own new instances. I found the problem: the terminal was running an ssh session to localhost. Ah yes, that would do it. I think you can detect this situation (no access to the interactive desktop or whatever is it called), if you wished to issue a suitable error message, by checking that OpenInputDesktop() returns non-NULL... Good idea, and that does seem to do the job. Opening a window in that situation seems to work fine anyway though. I guess it goes to some hidden desktop. Can anyone think of a sensible use case for that, i.e. should I make this a warning rather than an error? Andy I have a feeling it could be useful someway. Why not a command switch: --allow_null_desktop or something? -- 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: gitk kills bash shell
On 9/28/2010 9:40 PM, Jeremy Ramer wrote: On Tue, Sep 28, 2010 at 1:01 PM, Ryan Johnsonryanj...@ece.cmu.edu wrote: This sounds suspiciously similar to a problem that hit me a while back: http://www.cygwin.com/ml/cygwin/2010-09/msg00225.html The short version is, running certain apps in the background triggers a bug in tty handling. Last I heard Corinna was having trouble diagnosing because the bug also kills strace :) No fix yet AFAIK. I was afraid of that. It just started happening for me after upgrading to cygwin 1.7, as well as to others in my company. One nice thing, at least, is it takes a very specific setup to trigger the bug. You may be able to get a usable workaround by changing how it's called (see the thread above for ideas). Hopefully we get a fix for this soon, though. 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: a2ps on Cygwin quietly exits with code 127 on Windows 7
On Fri, 2010-07-30 at 17:24 -0500, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-27 at 01:51 -0400, Rasputin Paskudniak wrote:
Yaakov,
I have tried compiling 4.14. Here is the last few lines of the make
output, with line numbers to compensate for line-breaks:
179 /bin/sh ../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -DLOCALEDIR=\/usr/local/share/locale\
-DSYSCONFFILE=\/usr/local/etc/a2ps.cfg\ -I. -I. -I.. -I.. -I../intl
-I.-g -O2 -c -o path-concat.lo path-concat.c
180 gcc -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/local/share/locale\
-DSYSCONFFILE=\/usr/local/etc/a2ps.cfg\ -I. -I. -I.. -I.. -I../intl
-I. -g -O2 -c path-concat.c -o path-concat.o
181 In file included from path-concat.c:30:
182 /usr/include/string.h:58: error: parse error before void
I got the same error, but haven't had a chance to figure it out. If the
a2ps maintainer doesn't appear soon then I'll try to take another look
at it.
Sorry for the delay, I haven't looked at this in a while. The
attached .cygport contains the workaround (namely the HAVE_MEMPCPY
define).
HTH,
Yaakov
--- origsrc/a2ps-4.14/configure.in 2007-05-01 23:35:49.0 -0500
+++ src/a2ps-4.14/configure.in 2010-09-29 05:27:02.670787200 -0500
@@ -208,6 +208,7 @@ AC_MSG_CHECKING(for PostScript fonts pat
# Find out if ghostscript is installed
ac_psfont_path=
for ac_dir in /usr/local/ghostscript/fonts \
+ /usr/share/ghostscript/fonts \
/usr/local/share/ghostscript/fonts;
do
if test cd $ac_dir 2/dev/null echo *.afm; then
--- origsrc/a2ps-4.14/ogonkify/configure.in 2007-12-28 20:05:05.0 -0600
+++ src/a2ps-4.14/ogonkify/configure.in 2010-09-29 05:26:32.049084300 -0500
@@ -22,6 +22,7 @@ AC_DEFUN([ad_IBMFONTS],
[AC_PATH_X
AC_MSG_CHECKING(for IBM font files)
for i in $x_libraries/X11/fonts/Type1 \
+ /usr/share/fonts/Type1 \
/usr/local/share/TeX/gs/fonts
do
if test -r $i; then
DESCRIPTION=Anything to PostScript converter
HOMEPAGE=http://www.gnu.org/software/a2ps/;
SRC_URI=mirror://gnu/a2ps/${P}.tar.gz
PATCH_URI=4.14-font-paths.patch
DIFF_EXCLUDES=doc
CPPFLAGS+= -DHAVE_MEMPCPY
NO_AUTOPOINT=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
makewhatis installation step
I just installed a2ps and then: Cygwin apropos a2ps a2ps: nothing appropriate Cygwin makewhatis -u Cygwin apropos a2ps a2ps (1) - format files for printing on a PostScript printer texi2dvi4a2ps(1) - Compile Texinfo and LaTeX files to DVI or PDF Cygwin So, wondering if it's standard for users to have to run makewhatis after an install or if that step is missing from a2ps's install script. Additional info: Cygwin uname -a CYGWIN_NT-5.1 COBQDPPJ1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Cygwin cygcheck -c a2ps Cygwin Package Information Package VersionStatus a2ps 4.13-1 OK Cygwin --Ken Nellis
Inconsistency in handling a DOS path between subversion commands
I'm using Cygwin's subversion package instead of the native win32 build provided by CollabNet. It seems to work very well with UNIX-like paths, but some commands doesn't seem to play well along with DOS paths. Please take a look into the following log - 'svn info' works fine with a DOS path but 'svn update' does not: trus...@vault ~/workspace/netty-4.0 $ uname -a CYGWIN_NT-6.1-WOW64 vault 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin trus...@vault ~/workspace/netty-4.0 $ cygcheck -c subversion Cygwin Package Information Package VersionStatus subversion 1.6.12-2 OK trus...@vault ~/workspace/netty-4.0 $ pwd /cygdrive/c/Users/trustin/workspace/netty-4.0 trus...@vault ~/workspace/netty-4.0 $ svn info 'C:\Users\trustin\workspace\netty-4.0' Path: C:\Users\trustin\workspace\netty-4.0 URL: https://svn.jboss.org/repos/netty/trunk Repository Root: https://svn.jboss.org/repos/netty Repository UUID: 109acb31-e253-0410-afc7-b0fd4c62c465 Revision: 2362 Node Kind: directory Schedule: normal Last Changed Author: trustin Last Changed Rev: 2362 Last Changed Date: 2010-09-09 19:59:22 +0900 (Thu, 09 Sep 2010) trus...@vault ~/workspace/netty-4.0 $ svn update 'C:\Users\trustin\workspace\netty-4.0' svn: Working copy 'C:\Users\trustin\workspace\netty-4.0' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) trus...@vault ~/workspace/netty-4.0 $ svn update '/cygdrive/c/Users/trustin/workspace/netty-4.0' At revision 2362. Thanks, Trustin Cygwin Configuration Diagnostics Current System Time: Wed Sep 29 23:22:07 2010 Windows 7 Ultimate Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: C:\Devel\Cygwin\usr\local\bin C:\Devel\Cygwin\bin C:\Devel\Cygwin\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Devel\Java\JDK\Sun1.6.0.21\bin C:\Devel\Java\Scala\2.8.0.final\bin C:\Devel\Java\Maven\bin C:\Devel\Java\JDK\Sun1.6.0.21\bin C:\Devel\Java\Maven\bin C:\Devel\Java\Scala\2.8.0.final\bin Output from C:\Devel\Cygwin\bin\id.exe UID: 1000(trustin) GID: 513(None) 513(None) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'trustin' PWD = '/cygdrive/c/Users/trustin/workspace/netty-4.0' CYGWIN = 'nodosfilewarning' HOME = '/cygdrive/c/Users/trustin' HOMEPATH = '\Users\trustin' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\trustin\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'vault' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 30 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/Users/trustin/workspace' USERDOMAIN = 'vault' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'trustin' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' JAVA_HOME = '/cygdrive/c/Devel/Java/JDK/Sun1.6.0.21' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\trustin' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\VAULT' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\trustin\AppData\Local' !C: = 'C:\Devel\Cygwin\bin' ProgramData = 'C:\ProgramData' SHLVL = '1' M2_HOME = '/cygdrive/c/Devel/Java/Maven' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'Microsoft XPS Document Writer' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '1e05' SCALA_HOME = '/cygdrive/c/Devel/Java/Scala/2.8.0.final' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '8' SESSIONNAME = 'Console' COMPUTERNAME = 'VAULT' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\Devel\Cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\Devel\Cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: f26384cf833ec47b Path: C:\Devel\Cygwin c: hd NTFS476837Mb 5% CP CS UN PA FC / d: cd N/AN/A e: cd N/AN/A s: net NTFS 3752570Mb 67% CP CS UN PAstore C:\Devel\Cygwin / system binary,auto C:\Devel\Cygwin\bin /usr/bin system binary,auto C:\Devel\Cygwin\lib /usr/lib
Re: Inconsistency in handling a DOS path between subversion commands
You're lucky if any DOS-like paths work for any svn commands. It's really a Unix-based tool and will not generally grok the C: and \ stuff. The occasional command *might* work, but it will be hit or miss. Better to use cygpath to convert and DOS-like names to Unix-like ones before feeding to svn ... Regards -- Eliot Moss -- 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: gitk kills bash shell
On Wed, Sep 29, 2010 at 12:28:51PM +0200, Ryan Johnson wrote: On 9/28/2010 9:40 PM, Jeremy Ramer wrote: On Tue, Sep 28, 2010 at 1:01 PM, Ryan Johnsonryanj...@ece.cmu.edu wrote: This sounds suspiciously similar to a problem that hit me a while back: http://www.cygwin.com/ml/cygwin/2010-09/msg00225.html The short version is, running certain apps in the background triggers a bug in tty handling. Last I heard Corinna was having trouble diagnosing because the bug also kills strace :) No fix yet AFAIK. I was afraid of that. It just started happening for me after upgrading to cygwin 1.7, as well as to others in my company. One nice thing, at least, is it takes a very specific setup to trigger the bug. You may be able to get a usable workaround by changing how it's called (see the thread above for ideas). Hopefully we get a fix for this soon, though. http://cygwin.com/ml/cygwin/2010-09/msg00852.html 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: gitk kills bash shell
On Tue, Sep 28, 2010 at 9:59 PM, Christopher Faylor wrote: On Tue, Sep 28, 2010 at 09:01:51PM +0200, Ryan Johnson wrote: Jeremy Ramer said: I have a very repeatable issue, but I'm not sure how to go about debugging it. I follow this process. 1) Start an rxvt bash shell 2) Go to a git repo folder 3) Start gitk gitk --all 4) Go back to bash and press any key except enter and bash closes I also get a similar problem with this process: 1) Start an rxvt bash shell 2) Go to a git repo folder 3) Start gitk gitk --all 4) Close gitk with the close button. Both gitk and bash close. Note that the issue does not happen if I don't start gitk as a background process. But then I can't use the shell. Any debugging tips? This sounds suspiciously similar to a problem that hit me a while back: http://www.cygwin.com/ml/cygwin/2010-09/msg00225.html The short version is, running certain apps in the background triggers a bug in tty handling. Last I heard Corinna was having trouble diagnosing because the bug also kills strace :) No fix yet AFAIK. This should be fixed in the now-building snapshot. I actually fixed the problem a while ago but a stupid typo prevented the fix from actually doing what I'd intended. http://cygwin.com/snapshots/ 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 Tested out the snapshot. It fixes my issue. Thanks! -- 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
use the list of files stored in a text file and process it
I store a list of files in a text file (test.txt) on Windows XP. I want to use the list of files and process it (e.g. ls). What is the command to do that? I tried the following commands but to no avail. $ cat test.txt test.txt $ cat test.txt | xargs ls : No such file or directory $ cat test.txt | xargs -delimiter=\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\n' ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\\n' ls xargs: Invalid input delimiter specification elimiter=\\n: the delimiter must be either a single cha racter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter=\\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ uname -srv CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 -- 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: use the list of files stored in a text file and process it
On Wed, Sep 29, 2010 at 03:39:10PM +, albert kao wrote: I store a list of files in a text file (test.txt) on Windows XP. I want to use the list of files and process it (e.g. ls). What is the command to do that? I tried the following commands but to no avail. $ cat test.txt test.txt $ cat test.txt | xargs ls : No such file or directory It looks like you have CRLF line endings in the file. Run test.txt through d2u and the above command should work. It looks like you can't just use xargs --delimiter since that option takes only a single character. So: d2u test.txt | xargs ls 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: use the list of files stored in a text file and process it
On Wed, Sep 29, 2010 at 9:39 AM, albert kao wrote: I store a list of files in a text file (test.txt) on Windows XP. I want to use the list of files and process it (e.g. ls). What is the command to do that? I tried the following commands but to no avail. $ cat test.txt test.txt $ cat test.txt | xargs ls : No such file or directory $ cat test.txt | xargs -delimiter=\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\n' ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\\n' ls xargs: Invalid input delimiter specification elimiter=\\n: the delimiter must be either a single cha racter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter=\\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ uname -srv CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 -- 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 $ ls $(cat test.txt) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How to set default $PATH without adding Windows path?
Cygwin and Cygwin-X terminals always have default $PATH containing all the Windows paths. This gives many problems both in the terminals running command line commands and also NetBeans IDE. How to change the default $PATH so it does not contain any Windows paths? i.e. just /usr/local/bin:/usr/bin:/bin This needs to be a global Windows default so that NetBeans IDE can pick up. Thanks! -- View this message in context: http://old.nabble.com/How-to-set-default-%24PATH-without-adding-Windows-path--tp29842033p29842033.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to set default $PATH without adding Windows path?
2010/9/29 cygwindummy liu...@gmail.com: Cygwin and Cygwin-X terminals always have default $PATH containing all the Windows paths. This gives many problems both in the terminals running command line commands and also NetBeans IDE. How to change the default $PATH so it does not contain any Windows paths? i.e. just /usr/local/bin:/usr/bin:/bin Permanently for the whole system echo PATH=/usr/local/bin:/usr/bin:/bin /etc/profile source /etc/profile Permanently for one user: echo PATH=/usr/local/bin:/usr/bin:/bin ~/.bashrc source ~/.bashrc Temporary for a single program start: env PATH=/usr/local/bin:/usr/bin:/bin netbeans.exe Permanetly for one program: echo export PATH=/usr/local/bin:/usr/bin:/bin netbeans-starter.bsh echo netbeans.exe netbeans-starter.bsh chmod +x netbeans-starter.bsh Adapt the names to your needs. Al -- 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: error: unable to remap - despite repeated rebaseall
Additional background: P4.dll is part of a perl extension library for Perforce, p4perl. I built the perl library from source, but it links with some pre-compiled libraries that come from Perforce. Those libraries *were* built for cygwin. The P4.pm perl extension would not build with gcc 4, so when I built it I used g++-3 for the compiler and linker. I have tried running rebaseall several times, all successfully. I have provided an additional filelist to rebaseall (with -T) to make sure that the P4.dll was included in the rebaseing, since the P4.dll was not installed by cygwin, so is not listed as an installed file. Any suggestions? Rebaseall bases by default only Cygwins builtin DLL. This is from a differnt context, but I guess the solution is similar. http://en.gentoo-wiki.com/wiki/Prefix/Cygwin#Rebase_all_with_user_list I also heard of a special rebase-perl script. Try to google for that. Al -- 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
diff issue
Greetings, All! I have strange (to me) issue that I'm not entirely sure how to interpret. Let's say I have two versions of the same batch file: The old version from CVS: rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list The new version I've imported to Subversion: @echo off rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list When I'm comparing them with my usual macro diff -bdu -x CVS -x .svn -I \$Id.*\$ -I \$Revision.*\$ -I \$Date.*\$ -I \$Author.*\$ --strip-trailing-cr -- '1/backup.bat' 'backup.bat' It telling me that $Id$ lines are differ. But when I remove the @echo off from second file, it telling me that files are identical (the expected result). Having hard times dechiphering man diff, so if anyone can enlighten me in simple words on the matter, I'd appreciate help greatly. -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.09.2010, 5:33 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
