Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 19 13:08, Charles Wilson wrote:
Corinna Vinschen wrote:
OTOH, if you have an idea how to solve the ALT + Cursor key problem
No, nothing obvious. I'd just turn on some of the debugging in the main
loop and see what happens to the keystrokes.
Got it. The Alt key is handled rather strange in Windows. For some
reason, some of the Alt-key combinations generate a WM_SYSCHAR message,
while other Alt-key combinations (Alt-Cursor, Alt-Fkey, etc) generate a
WM_SYSKEYDOWN message only.
rxvt already handles *one* *single* *key* *combination* specially,
Alt-F10. I have no idea what's so special with Alt-F10, but there you
are. This special handling is not necessary, it even looks a bit wrong.
The patch to get all missing Alt-key combinations working is quite
simple:
--- W11/w32/event.c.ORIG2007-08-20 12:56:25.637210400 +0200
+++ W11/w32/event.c 2007-08-20 13:09:55.322732400 +0200
@@ -127,11 +127,6 @@ doTranslateMessage(MSG *m)
((m-wParam == VK_BACK) ||
(((m-wParam == VK_ADD) || (m-wParam == VK_SUBTRACT))
(GetKeyState(VK_SHIFT) 0x8000 return;
- if ((m-message == WM_SYSKEYDOWN) (m-wParam == VK_F10))
- {
- m-message = WM_KEYDOWN;
- return;
- }
TranslateMessage(m);
}
@@ -205,7 +200,8 @@ LONG NT_handleMsg(
case WM_QUIT:
case WM_CLOSE:
case WM_DESTROY:
- case WM_SYSCHAR:/* alt-keys go here */
+ case WM_SYSKEYDOWN: /* Some alt-keys go here */
+ case WM_SYSCHAR:/* Other alt-keys go here */
case WM_CHAR:
case WM_LBUTTONDBLCLK:
case WM_MBUTTONDBLCLK:
@@ -543,6 +539,7 @@ WinEventToXEvent(
}
event-xkey.window=(Window)window;
break;
+ case WM_SYSKEYDOWN:
case WM_KEYDOWN:
event-type=KeyPress;
switch (wParam)
This works fine for me. All other, already working Alt-key combinations
still work, plus the new Alt-Cursor, Alt_Fkey, etc. Even Alt-F10 works
as before. I'm going to use this patch locally anyway, but maybe that's
one for inclusion upstream?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: RXVT doesn't recognize ALT + Cursor keys
Corinna Vinschen wrote: as before. I'm going to use this patch locally anyway, but maybe that's one for inclusion upstream? As far as I know, there is no upstream rxvt -- it's a dead project. The rxvt-unicode fork is where new development happens. I'm not sure what that means exactly for the W11/Win32 parts of rxvt. I'm sure Chuck could answer this a lot more definitively. Brian
Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 20 04:25, Brian Dessent wrote: Corinna Vinschen wrote: as before. I'm going to use this patch locally anyway, but maybe that's one for inclusion upstream? As far as I know, there is no upstream rxvt -- it's a dead project. The rxvt-unicode fork is where new development happens. I'm not sure what that means exactly for the W11/Win32 parts of rxvt. I'm sure Chuck could answer this a lot more definitively. It makes still sense for Cygwin, isn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 20 13:59, Corinna Vinschen wrote: On Aug 20 04:25, Brian Dessent wrote: Corinna Vinschen wrote: as before. I'm going to use this patch locally anyway, but maybe that's one for inclusion upstream? As far as I know, there is no upstream rxvt -- it's a dead project. The rxvt-unicode fork is where new development happens. I'm not sure what that means exactly for the W11/Win32 parts of rxvt. I'm sure Chuck could answer this a lot more definitively. It makes still sense for Cygwin, isn't it? I'm just a bit puzzled about the key codes. By default, when rxvt is invoked without explicitely setting the terminal name (-tn option), rxvt is recognized as an xterm. The cursor keys correctly return ESC [ A to ESC [ D. However, the Home and End keys return ESC [ 7 ~ and ESC [ 8 ~, while a real xterm returns ESC [ H and ESC [ F. Ok, so I set the terminal to rxvt-cygwin-native as suggested in the README file. Now the Home and End keys are ok, because the termcap/terminfo entry for these keys is matching. However, the termcap/terminfo entries expect ESC O A to ESC O D for the cursor keys but, as I wrote above, rxvt returns the xterm sequences ESC [ A to ESC [ D, so the cursor keys don't work anymore. So the question is, how is that supposed to work? Wouldn't it make sense to change the escape sequences of Home and End key to their xterm equivalents and drop the idea to set TERM to rxvt-cygwin-native? At least this looks like the simpler approach, rather than changing the termcap/terminfo entries of the world... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 20 16:06, Corinna Vinschen wrote: I'm just a bit puzzled about the key codes. By default, when rxvt is invoked without explicitely setting the terminal name (-tn option), rxvt is recognized as an xterm. The cursor keys correctly return ESC [ A to ESC [ D. However, the Home and End keys return ESC [ 7 ~ and ESC [ 8 ~, while a real xterm returns ESC [ H and ESC [ F. Ok, so I set the terminal to rxvt-cygwin-native as suggested in the README file. Now the Home and End keys are ok, because the termcap/terminfo entry for these keys is matching. However, the termcap/terminfo entries expect ESC O A to ESC O D for the cursor keys but, as I wrote above, rxvt returns the xterm sequences ESC [ A to ESC [ D, so the cursor keys don't work anymore. On further looking into this, it appears that the termcap/terminfo entries are wrong. ESC O A to ESC O D are only generated after entering the DEC expanded cursor mode with ESC [ ? 1 h. The default codes are ESC [ A to ESC [ D. It's not clear to me why the termcap/terminfo entries list the expanded mode sequences instead of the standard sequences. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 20 16:44, Corinna Vinschen wrote: On Aug 20 16:06, Corinna Vinschen wrote: I'm just a bit puzzled about the key codes. By default, when rxvt is invoked without explicitely setting the terminal name (-tn option), rxvt is recognized as an xterm. The cursor keys correctly return ESC [ A to ESC [ D. However, the Home and End keys return ESC [ 7 ~ and ESC [ 8 ~, while a real xterm returns ESC [ H and ESC [ F. Ok, so I set the terminal to rxvt-cygwin-native as suggested in the README file. Now the Home and End keys are ok, because the termcap/terminfo entry for these keys is matching. However, the termcap/terminfo entries expect ESC O A to ESC O D for the cursor keys but, as I wrote above, rxvt returns the xterm sequences ESC [ A to ESC [ D, so the cursor keys don't work anymore. On further looking into this, it appears that the termcap/terminfo entries are wrong. ESC O A to ESC O D are only generated after entering the DEC expanded cursor mode with ESC [ ? 1 h. The default codes are ESC [ A to ESC [ D. It's not clear to me why the termcap/terminfo entries list the expanded mode sequences instead of the standard sequences. I'd like to suggest the below patch. It aligns the handling of Home and End key to its xterm counterparts. That doesn't solve the problem with the rxvt-cygwin-native termcap/terminfo entries, but it let rxvt work better in default xterm mode. Home and End now generate the vt102/vt220/xterm sequence ESC [ H and ESC [ F. After switching to the DEC extended cursor mode, they generate ESC O H and ESC O F, same as vt102/vt220/xterm. Corinna --- command.c.ORIG 2007-08-20 16:51:43.419482700 +0200 +++ command.c 2007-08-20 16:55:20.632170700 +0200 @@ -465,6 +465,8 @@ rxvt_lookup_key(rxvt_t *r, XKeyEvent *ev #endif case XK_End: STRCPY(kbuf, KS_END); + if (r-h-PrivateModes PrivMode_aplCUR) + kbuf[1] = 'O'; break; #ifdef XK_KP_Home case XK_KP_Home: @@ -477,6 +479,8 @@ rxvt_lookup_key(rxvt_t *r, XKeyEvent *ev #endif case XK_Home: STRCPY(kbuf, KS_HOME); + if (r-h-PrivateModes PrivMode_aplCUR) + kbuf[1] = 'O'; break; #define FKEY(n, fkey) \ --- command.h.ORIG 2007-08-20 16:56:10.099082700 +0200 +++ command.h 2007-08-20 16:56:20.687946700 +0200 @@ -38,8 +38,8 @@ # define KS_HOME \033[1~ /* Home == Find */ # define KS_END\033[4~ /* End == Select */ #else -# define KS_HOME \033[7~ /* Home */ -# define KS_END\033[8~ /* End */ +# define KS_HOME \033[H/* Home */ +# define KS_END\033[F/* End */ #endif #ifdef SCROLL_ON_SHIFT -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Please upload: mathomatic-12.7.5-1
Please upload: http://rurban.xarch.at/cygr/mathomatic/mathomatic-12.7.5-1.tar.bz2 http://rurban.xarch.at/cygr/mathomatic/mathomatic-12.7.5-1-src.tar.bz2 setup.hint unchanged mathomatic-12.7.0-1 can be deleted (if wanted) -- Reini
[ITA] fvwm 2.5.21 -- F Virtual Window Manager
Adopted from Harold. Updated to new upstream version. Jari sdesc: F Virtual Window Manager ldesc: A powerful ICCCM2 compliant multiple virtual desktop window manager for the X Window System. FVWM requires relatively little memory. category: X11 requires: cygwin libXft2 libexpat0 libfontconfig1 libfreetype26 libiconv2 libin\tl8 libncurses8 libpng12 perl readline xorg-x11-base xorg-x11-bin-dlls zlib a) manual downlaod wget\ http://cygwin.cante.net/fvwm/fvwm-2.5.21-1.tar.bz2 \ http://cygwin.cante.net/fvwm/fvwm-2.5.21-1-src.tar.bz2 \ http://cygwin.cante.net/fvwm/setup.hint b) automated: get.sh displays further instructions gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir fvwm ; cd fvwm rm -f get.sh get.sh.sig wgethttp://cygwin.cante.net/fvwm/get.sh \ http://cygwin.cante.net/fvwm/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh
Re: RXVT doesn't recognize ALT + Cursor keys
Brian Dessent wrote: Corinna Vinschen wrote: as before. I'm going to use this patch locally anyway, but maybe that's one for inclusion upstream? As far as I know, there is no upstream rxvt -- it's a dead project. The rxvt-unicode fork is where new development happens. I'm not sure what that means exactly for the W11/Win32 parts of rxvt. I'm sure Chuck could answer this a lot more definitively. Brian's right: upstream rxvt is dead, and rxvt-unicode is where the action is. However, rxvt-unicode does not (yet) have any mechanism for non-X11 operation, so I'll keep cygwin's rxvt going. More downthread. -- Chuck
Re: RXVT doesn't recognize ALT + Cursor keys
Corinna Vinschen wrote: I'm just a bit puzzled about the key codes. By default, when rxvt is invoked without explicitely setting the terminal name (-tn option), rxvt is recognized as an xterm. This is a configure option for rxvt (--with-term=) which defaults to xterm. There are a few differences between rxvt (and rxvt-native-cygwin and rxvt-cygwin) and xterm, such as the ACS character codes -- and Home, End, Delete, and BackSpace handling. (Original xterm didn't even specify Home/End. Ones newer than ten years do, tho, only differently than rxvt). I've always thought rxvt should report 'rxvt', but since SteveO's original version used the default 'xterm' settings, I've never changed it. It *mostly* works in that mode -- and 'xterm' is ALWAYS available in /etc/termcap or */terminfo/*, while even the undecorated 'rxvt' might be missing. Like on gentoo-embedded without ncurses-extra-terminfo installed. So, in the absence of -tn, cygwin's rxvt will continue to default to 'xterm' -- but 'xterm' is NOT a perfect match for rxvt's terminal handling, and we shouldn't try to make it so. If we did, then cygwin's rxvt would just be broken on systems that actually HAVE the correct (undecorated) 'rxvt' terminfo installed. However, if it is the list's opinion, I'm willing to be persuaded that cygwin's rxvt should default to setting TERM=rxvt in the absence of -tn... The cursor keys correctly return ESC [ A to ESC [ D. However, the Home and End keys return ESC [ 7 ~ and ESC [ 8 ~, while a real xterm returns ESC [ H and ESC [ F. From the terminfo.src file, distributed with ncurses, in the xterm-color section: This description [ed: of xterm-color] is compatible with color_xterm, rxvt and XFree86 xterm, except that each of those implements the home, end, delete keys differently. So, yeah, here's what terminfo.src says about rxvt-basic: # Normal ShiftControl Ctrl+Shift # Tab ^I ESC [ Z ^I ESC [ Z # BackSpace^H ^? ^? ^? # Find ESC [ 1 ~ESC [ 1 $ESC [ 1 ^ESC [ 1 @ # Insert ESC [ 2 ~pasteESC [ 2 ^ESC [ 2 @ # Execute ESC [ 3 ~ESC [ 3 $ESC [ 3 ^ESC [ 3 @ # Select ESC [ 4 ~ESC [ 4 $ESC [ 4 ^ESC [ 4 @ # PriorESC [ 5 ~scroll-upESC [ 5 ^ESC [ 5 @ # Next ESC [ 6 ~scroll-down ESC [ 6 ^ESC [ 6 @ # Home ESC [ 7 ~ESC [ 7 $ESC [ 7 ^ESC [ 7 @ # End ESC [ 8 ~ESC [ 8 $ESC [ 8 ^ESC [ 8 @ # Delete ESC [ 3 ~ESC [ 3 $ESC [ 3 ^ESC [ 3 @ # F1 ESC [ 11 ~ ESC [ 23 ~ ESC [ 11 ^ ESC [ 23 ^ ... more function keys ... # Up ESC [ A ESC [ a ESC O a ESC O A # Down ESC [ B ESC [ b ESC O b ESC O B # RightESC [ C ESC [ c ESC O c ESC O C # Left ESC [ D ESC [ d ESC O d ESC O D # KP_Enter ^M ESC O M # KP_F1ESC O PESC O P # KP_F2ESC O QESC O Q # KP_F3ESC O RESC O R # KP_F4ESC O SESC O S # XK_KP_Multiply * ESC O j # XK_KP_Add+ ESC O k # XK_KP_Separator , ESC O l # XK_KP_Subtract - ESC O m # XK_KP_Decimal. ESC O n # XK_KP_Divide / ESC O o # XK_KP_0 0 ESC O p ... more keypad numbers ... Ok, so I set the terminal to rxvt-cygwin-native as suggested in the README file. Frankly, plain old rxvt (or rxvt-color, or rxvt-xpm: all three are identical) will work just as well. The only difference between the cygwin variants and rxvt is the ACS charset. And the two cygwin variants differ between each other in only ONE character in that charset. Now the Home and End keys are ok, because the termcap/terminfo entry for these keys is matching. However, the termcap/terminfo entries expect ESC O A to ESC O D for the cursor keys but, as I wrote above, rxvt returns the xterm sequences ESC [ A to ESC [ D, so the cursor keys don't work anymore. I used to have to fix my /etc/termcap. But now the /etc/termcap in termcap-20050421-1.tar.bz2 says: rxvt|rxvt terminal emulator (X Window System):\ :am:eo:km:mi:ms:xn:xo:\ :co#80:it#8:li#24:\ :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\ :K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\ :RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:\
Re: RXVT doesn't recognize ALT + Cursor keys
Corinna Vinschen wrote: On further looking into this, it appears that the termcap/terminfo entries are wrong. ESC O A to ESC O D are only generated after entering the DEC expanded cursor mode with ESC [ ? 1 h. The default codes are ESC [ A to ESC [ D. From what I can tell, the expanded codes SHOULD be ESC [ n A where n is 1-9, not 0 (and '[' should be there) and should be emitted when in DECCKM mode. This stuff is all handled in src/command.c but it's a twisty maze that all looks the same. It's not clear to me why the termcap/terminfo entries list the expanded mode sequences instead of the standard sequences. Referring to my previous message, I don't see that in termcap/terminfo at all. All I see is the correct ESC [ A and friends. -- Chuck
Re: RXVT doesn't recognize ALT + Cursor keys
Charles Wilson wrote: Thanks. I'll include this in the next build. In fact, I'm going to generate a test release using this patch, and --with-term=rxvt -- but without the 'make cygwin rxvt act like xterm, even though all other rxvt do not' patch. I really think that issue is a bug in your termcap/terminfo files, because mine don't specify the things your do. I'll post an archive with my precompiled terminfo/r/rxvt* files and /etc/termcap, for testing. rxvt-20050409-5 should propagate to the mirrors soon (as test release). Try it with the attached termcap/terminfo files. -- Chuck rxvt-term.tar.bz2 Description: Binary data
Re: openbox works, but how do I get the middle mouse button to display a menu?
John F Davis wrote: Hello I have openbox working, but when I click my middle mouse button on my windows desktop it opens windows desktop dialog. On a related issue, if I use openbox and icon a window, I can not access the windows anymore. Openbox on linux accesses the icon'd windows via the middle mouse button clicked on the desktop. Please advise. JD Do you have -emulate3buttons set on your server? If so, you need to press buttons 1 and 2 (left and right) at the same time to emulate the middle/third button. It doesn't sound like this is what you want, so make sure you're not starting X with this parameter (check your startup script). Otherwise, what type of mouse and mouse driver do you have? Some drivers will change the behavior of the middle button so X doesn't recognize it. Cary -- 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: FW: X forward question
Thanks for reply. So, do you think that windows 2003 server is the solution for my goal? Or any other options I have. Please give me some suggestion. Basically I need to set up a super computer which allows several clients to run applications for computing simultaneously. I think the windows are the best environments since most of users are familiar windows systems. Thanks. liang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Hall (Cygwin X) Sent: Sunday, August 19, 2007 10:36 PM To: cygwin-xfree@cygwin.com Subject: Re: FW: X forward question liang wrote: From: liang [mailto:[EMAIL PROTECTED] Sent: Sunday, August 19, 2007 3:40 PM To: 'cygwin-xfree@cygwin.com' Subject: X forward question Hi, 1. I just to subscribe the mailing list, so I can reply the email now. Sorry to start a new thread. 2. I start x server with double click startxwin.bat under /etc/x11r/bin, a window starts and X show in the system tray. 3. I typed xterm and start a new window 4. In new window, I typed ssh –Y –v –l ZwLi 192.168.1.101 (internal network, wireless) $ssh -Y -v -l ZwLi 192.168.1.101 OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Connecting to 192.168.1.101 [192.168.1.101] port 22. debug1: Connection established. debug1: identity file /home/swang/.ssh/identity type -1 debug1: identity file /home/swang/.ssh/id_rsa type -1 debug1: identity file /home/swang/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.6 debug1: match: OpenSSH_4.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.1.101' is known and matches the RSA host key. debug1: Found key in /home/swang/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/swang/.ssh/identity debug1: Trying private key: /home/swang/.ssh/id_rsa debug1: Trying private key: /home/swang/.ssh/id_dsa debug1: Next authentication method: password [EMAIL PROTECTED]'s password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. Last login: Sun Aug 19 15:05:49 2007 from unc-zofo4lkabzt [EMAIL PROTECTED] ~ $ 5. I believe that I logged on the sshd server on ZwLi computer. 6. Typed cd /cygdrive/c/program\ files/picasa2 to change folder on the server 7. Typed ./picasa2.exe and tried to run picasa to test if X forwarding is working 8. I can see the picasa2.exe running on my sshd server since I can see a process running in the windows task manager on the server. But there is nothing happened in my ssh client end. Do I suppose to see a picasa2 window opened in ssh client end? No. You're running a MS Windows program that knows nothing about X. Cygwin's X server will not magically transform the output of Windows programs into X windows locally or otherwise. 9. Before I started my ssh session, I typed display=localhost:0.0 Export display after I started X server Don't do this. It's not needed and it's not correct. 10. My sshd server and client are both running on XP professional 11. I desparately need to run Rgui on my sshd server from ssh client. I didn’t install X server on the computer running sshd server. Do I miss something? Or I am totally wrong. My goal is to run windows application on the sshd server from every ssh client (both sshd server and ssh client installed XP). See above. 12. I replaced “#X11forward no” with “X11forward yes” in the file sshd_config on sshd server. But I didn’t revise ssh_config on the ssh client machine since I cannot find the file ssh_config under /etc/ folder. Please give me some helps. And thank everybody who replyed my email before. I think you're looking at the wrong software to solve your problem. If you just want to run Windows programs on other machines, you can always try connecting to a shared drive on the server and running the installed program from the client. But you're not going to find Cygwin X helps you do this. -- Larry Hall
Re: FW: X forward question
http://cygwin.com/acronyms/#TOFU. Reformatted. liang wrote: -Original Message- Subject: Re: FW: X forward question liang wrote: From: liang [mailto:swang2000ATgmailDOTcom] ^^^ Sent: Sunday, August 19, 2007 3:40 PM To: 'cygwin-xfreeATcygwinDOTcom' ^^ http://cygwin.com/acronyms/#PCYMTNQREAIYR. Yes, I know gmail doesn't do this kind of thing automatically but it never hurts to ask. In the meantime you're left with manual editing. A pain, I know. But it's better than opening yourself and others up to spamming. I think you're looking at the wrong software to solve your problem. If you just want to run Windows programs on other machines, you can always try connecting to a shared drive on the server and running the installed program from the client. But you're not going to find Cygwin X helps you do this. Thanks for reply. So, do you think that windows 2003 server is the solution for my goal? Or any other options I have. Please give me some suggestion. Basically I need to set up a super computer which allows several clients to run applications for computing simultaneously. I think the windows are the best environments since most of users are familiar windows systems. If you want users to be able to log into your machine and run Windows GUI (and command line) programs from that machine, you're probably best off setting it up as a Windows server machine, yes. Users can connect through Terminal Services to run a desktop on the server and invoke programs from there. Discussion of things other than Cygwin-X is really off-topic for this list though. I'd suggest if you have more questions about setting up a machine to act as a server for stock Windows applications, you should take them to the proper Windows forum. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 429-6305 - FAX Holliston, MA 01746 -- 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/
Adding fonts
Hi, Is there a simple way to add fonts to Cygwin's X server? For example, I have a true-type font called TAHOMA.TTF that I would like to make available to the X Server. Are all the host operating system's fonts automatically available to the X server? Do I have to perform any special actions to enable them? Is there a formula for doing this? Thanks in advance, list. J -- 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: Cygwin X server 'reset' command
On Mon, 20 Aug 2007, Jean-Claude Gervais wrote: Hello, I am using the Xterm that ships with Cygwin. I forget (xterm -v would show the patch level), but Cygwin's got a moderately old xterm. See http://invisible-island.net/xterm/xterm.log.html for details on xterm's versions. When I connect by ssh to a host running Linux, I can run the 'reset' command on that host to clear my xterm and erase its backscroll history. ...sounds right However, when I am not logged onto a host and execute the 'reset' command locally, it seems to have no effect. ...sounds as if $TERM isn't set properly In a console-mode bash prompt (cygwin.bat), same behaviour, but I have noticed executing the command 'cmd /c cls' works in this case but not in the graphical xterm. Although it is not a big problem, I am curious; is there a way to clear the backscroll buffer? The 'clear' command does clear the current screen but not the entire history. reset should behave the same (on the regular cygwin list there's more likelihood that you'd get an answer for this). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin X server 'reset' command
Why don't you try this on the command line: printf \ec If this works, then you can probably insert this line in your .bashrc/.bash_profile alias cls=`printf \ec` and use cls henceforth. Regards, Mansoorali. On 8/21/07, Jean-Claude Gervais [EMAIL PROTECTED] wrote: Hello, I am using the Xterm that ships with Cygwin. When I connect by ssh to a host running Linux, I can run the 'reset' command on that host to clear my xterm and erase its backscroll history. However, when I am not logged onto a host and execute the 'reset' command locally, it seems to have no effect. In a console-mode bash prompt (cygwin.bat), same behaviour, but I have noticed executing the command 'cmd /c cls' works in this case but not in the graphical xterm. Although it is not a big problem, I am curious; is there a way to clear the backscroll buffer? The 'clear' command does clear the current screen but not the entire history. Thank you J -- 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/ -- 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 fhandler.cc winsup.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-08-20 15:16:27 Modified files: winsup/cygwin : ChangeLog fhandler.cc winsup.h Log message: * fhandler.cc (rootdir): Delete. * winsup.h (rootdir): Drop declaration. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3915r2=1.3916 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.300r2=1.301 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/winsup.h.diff?cvsroot=srcr1=1.203r2=1.204
src/winsup/cygwin ChangeLog hookapi.cc path.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-08-20 15:41:10 Modified files: winsup/cygwin : ChangeLog hookapi.cc path.h Log message: * hookapi.cc (ld_preload): Call LoadLibraryW. * path.h (path_conv::get_wide_win32_path_len): Define. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3916r2=1.3917 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/hookapi.cc.diff?cvsroot=srcr1=1.13r2=1.14 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srcr1=1.108r2=1.109
Re: Problem running wget
Rafael Anschau wrote: Wget won´t output anything on the screen. bash-3.2$ pwd / bash-3.2$ cd bin bash-3.2$ ./wget bash-3.2$ cd /usr/bin bash-3.2$ ./wget bash-3.2$ Any sugestions ? wget is linked against the openssl libraries, but according to your cygcheck output you're missing cygcrypto-0.9.8.dll and cygssl-0.9.8.dll (and probably others) so wget cannot initialize. You can verify this with cygcheck /usr/bin/wget which should list the missing dlls. Exit code 53 is returned when a program cannot run due to missing libraries, which you can verify with echo $?. Re-run setup and select Reinstall for openssl and any other packages that are not installed properly. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: Unicode text editor mined 2000 release 14
mined 2000 release 14 (July 2007) Mined is a powerful text editor with a comprehensive yet concise and easy-to-use user interface supporting modern interaction paradigms, and fast, small-footprint behaviour. Mined provides both extensive Unicode and CJK support offering many specific features and covering special cases that other editors are not aware of (like auto-detection features and automatic handling of terminal variations, or Han character information). It was the first editor that supported Unicode in a plain-text terminal (like xterm or rxvt). Basically, mined is an editor tailored to reliable and efficient editing of plain text documents and programs, with features and interactive behaviour designed for this purpose. Following: * Hints and links * Major enhancements in this release * Mined Overview To install mined on cygwin, run the cygwin setup program, in the Select Packages menu, open the Editors category and select the mined package. More information (with screenshots, feature overview and change log) and download are available from the mined web site at http://towo.net/mined/ Mined is co-hosted at sourceforge and has a mailing list which can be subscribed at https://lists.sourceforge.net/lists/listinfo/mined-editor Major enhancements in this release: Text editing features: * Case-insensitive search (except when searching for an identifier). * New command Alt-x toggles preceding character and its hexadecimal code. Character encoding support enhancements: * Additional option -E? just determines and displays text file encoding(s). * Additional option +E? just determines and displays terminal encoding. * Separated display of isolated combining characters (e.g. after TAB). * Improved text encoding auto-detection: * Improved detection of CJK encodings vs. 8-bit encodings. * Added auto-detection of Windows-ANSI (CP1252), PC-Latin (CP850), MacRoman. * Improved configuration of auto-detection. Character input enhancements: * New shortcuts for input of plain quote marks (in smart quotes mode). Interworking enhancements: * Terminal encoding handling: * Added options -f / -F to indicate limited font coverage of special characters. * Detecting and handling non-Unicode terminal with Arabic ligature joining. * Detecting and handling special width behaviour of rxvt, mlterm, konsole concerning unassigned characters, non-BMP, or non-Unicode characters. * Applying display replacement for illegal Unicode characters by default (codes ending with FFFE/, surrogates, non-Unicode code points). * Fixed a lot of other remaining width display inconsistencies. * Making use of window focus out/in reports (xterm 224). * Workaround for xterm 224 bug which could lock up the terminal. * Adjusting display details to properties of gnome-terminal, konsole. * Considering termcap information of function key escape sequences. Miscellaneous changes: * Increased speed of some UTF-8 search operations by a factor of ~ 40. * Colour highlighting of DOS/Mac line end indications. Feature Overview Good interactive features * Intuitive user interface * Logical and consistent concept of navigating and editing text (without ancient line-end handling limitations or insert/append confusion) * Supports various control styles: - Editing with command control, function key control, or menu control - Navigation by cursor keys, control keys, mouse or scrollbar * Concise and comprehensive menus (driven by keyboard or mouse) * HOP key paradigm doubles the number of navigation functions that can be most easily reached and remembered by intuitively amplifying the associated function * Immediate adjustment if the window size is changed, in any state of interaction Versatile character encoding support * Extensive Unicode support, including double-width and combining characters, script highlighting, various methods of character input support (mapped keyboard input methods, mnemonic and numeric input), supporting CJK, Vietnamese, Hebrew, Arabic, and other scripts * Extensive accented character input support, including multiple accent prefix keys. * Support for Greek (monotonic and polytonic). * Support for Cyrillic accented characters. * Support of bidirectional terminals, Arabic ligature joining * East Asian character set support: handling of major CJK encodings (including GB18030 and full EUC-JP with combining characters) * Support for a large number of 8 bit encodings (with combining characters for Vietnamese, Thai, Arabic, Hebrew) * Support of CJK input methods by enhanced keyboard mapping including multiple choice mappings (handled by a pick list menu); characters
Re: RXVT doesn't recognize ALT + Cursor keys
On Aug 19 13:55, Andrew DeFaria wrote: I understand, however even as a vi user you use the j and k keys for up and down movement, the h and l keys for left and right movement and the w for word forward forward, b for word back no? I've always heard that the reason for that is to more efficiently do movement while leaving your fingers on the home row. If that's true then why then reorient your hands off home row to do word movement just for the command line? Just something to think about... Habit? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Line info causes GCC to bomb?
On 19 August 2007 21:24, [EMAIL PROTECTED] wrote:
I haven't seen this problem anywhere in the list archive, so
here it is.
This preprocessed input causes GCC (3.4.4) to segfault
# 1 test.c 1
int main () {
return 0;
}
... and this doesn't:
# 1 test.c
# 1 test.c 1
int main () {
return 0;
}
Am I missing something?
Nope, I can reproduce it.
Was it you or gcc that generated that preprocessed file? It obviously
shouldn't crash, but it's a much higher priority if gcc itself generates
invalid preprocessed output than if it gets confused by something you've
hand-generated (or post-pre-processed!) yourself.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Problem with Text mounts after updating using setup.exe
Could someone confirm this is introduced in grep-2.5.1a-4, grep-2.5.1a-2 seems to be good? Greets, Bart -Original Message- From: Bart van der Werf Sent: Wednesday, August 15, 2007 10:44 AM To: cygwin@cygwin.com Subject: Problem with Text mounts after updating using setup.exe After upgrading cygwin some of my textmode mount files started to have additional 0x0d characters. Example of problem. With a file test.txt $ od -t x1 test.txt 000 61 0d 0a 62 0d 0a 63 0d 0a 011 with dos style newlines. $ grep a test.txt test2.txt If i invoke grep on this file, i get the problem that it duplicates the 0x0d $ od -t x1 test2.txt 000 61 0d 0d 0a 004 I started getting this problem after running setup.exe this week. The version of cygwin before the upgrade was atleast a year old. What should i do ? Do i need to provide additional information ? I wouldn't expect an additional 0x0d even if the mount was in binmode. greeting Bart van der Werf -- 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/
Copy/Paste doesn't run on Cygwin
Hi, Without the .vimrc file the copy/paste runs fine in a vim's edited file, but when I copy the example vimrc file (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text isn't copy automatically on the clipboard. The .vimrc is attached. http://www.nabble.com/file/p12232667/.vimrc .vimrc Some information about Cygwin is attached too. http://www.nabble.com/file/p12232667/cygcheck.out cygcheck.out The vim version is: $ vim --version VIM - Vi IMproved 7.1 (2007 May 12, compiled May 14 2007 16:29:51) Compilado por [EMAIL PROTECTED] Versión «enorme» sin GUI. Aspectos incluidos (+) o no (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save fichero «vimrc» del sistema: $VIM/vimrc fichero «vimrc» del usuario: $HOME/.vimrc fichero «exrc» del usuario: $HOME/.exrc localización de $VIM: /usr/share/vim Compilación: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 Enlazado: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl Any help? Thanks in advance, Jose Luis -- View this message in context: http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12232667 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Fw: clear
Hello, I have just reinstalled cygwin from scratch (deleted c:\cygwin directory) and noticed that the clear command was not in /usr/bin anymore. In Cygwin Package List, it says that clear was removed and that ncurses should be used instead (?). However, libncurses7 and libncurses8 ARE installed on my machine, according to setup.exe, which means, I guess, that ncurses is installed. How do you use ncurses clear command, if there is such a thing? Many thanks. Best regards, Philippe -- 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: rsync problems from Vista installed cygwin, ok on XP
Corinna Vinschen-2 wrote: On Aug 18 21:06, DaveB wrote: So... two interesting followon points... 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in the first place when I created this little test area in Vista? After all, I The directory has been created using native Windows tools. The permissions given using native Windows tools *are* strange and don't follow POSIX rules. It's perfectly valid that you can access a directory under Windows but get 000 POSIX permissions. You did see the '+' at the end of the permission in ls -l? OK, I now see this + and had no idea what it meant... but have now found the doc in cygwin by typing info ls, where it says... Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. For a file with an extended access control list, a `+' character is listed. Basic access control lists are equivalent to the permissions listed, and are not considered an alternate access method. Interesting. So if it knows there is an ACL which overrides the -- permissions that were inherited from C:\ then why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files... even if it cannot directly read the ACL maybe it could allow you to invoke some special rsync permissions sync'ing flag? I looked in the man rsync doc, and found some flags that might be helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite let you do automatically what would make sense, which is to create rsync'd files with rwx for the exe's and rw for the others. Not sure what the best way out of here is...??? I'm beginning to understand this a bit better, but it sure is a minefield... will generate ongoing problems for innocent future users. PS Can anyone point to a good article on ACL that explains the relationship to these ls -l permissions also? -- View this message in context: http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12232786 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: clear
On 20 August 2007 10:30, [EMAIL PROTECTED] wrote: Hello, I have just reinstalled cygwin from scratch (deleted c:\cygwin directory) and noticed that the clear command was not in /usr/bin anymore. In Cygwin Package List, it says that clear was removed and that ncurses should be used instead (?). However, libncurses7 and libncurses8 ARE installed on my machine, according to setup.exe, which means, I guess, that ncurses is installed. How do you use ncurses clear command, if there is such a thing? I dunno, but here's a couple of alternatives: alias clear='cmd /c cls' alias clear='echo -e \033c' The cmd.exe-based one works best in a cygwin DOS-console shell, the echo version works best in a proper console like rxvt/xterm. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: clear
[EMAIL PROTECTED] wrote: In Cygwin Package List, it says that clear was removed and that ncurses should be used instead (?). However, libncurses7 and libncurses8 ARE installed on my machine, according to setup.exe, which means, I guess, that ncurses is installed. No, it means that libncurses is installed. There is also a 'ncurses' package, and that is what contains the clear command. (You can look this up yourself using the Package Search page.) The reasoning for why packages are split like this has many reasons. For one thing, it allows library versioning, where you have multiple packages compiled against multiple versions of the library. For another, it allows installing just the binary runtime components of a library, without pulling in all the other nonessential parts just because the user happened to have installed a package that is linked against that library. And that is just what has happened in this case. Brian -- 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: Permission denied problem
On 17 August 2007 17:35, Dave Korn For comparison, what does the standard windows 'cacls.exe' utility tell you about that directory, and about one where the problem doesn't happen? cacls will certainly be of great help, thanks a lot. Here is what I get for the directory without problems: $ cacls 'x:\02_0024\PPP' x:\02_0024\PPP NT AUTHORITY\SYSTEM:(OI)(CI)F CORP\AllShareAdminGroup:(OI)(CI)F CORP\AllShareListGroup:(CI)R CORP\13.G__Access_Admin:R CORP\13.G__R_D_ITS:R CORP\13.G__Spark_International:R CORP\13.G__Team_Access_Admin:R CORP\16.0024_MO_Access_Admin:R CORP\13.G__Assistant:R CORP\13.G__Team_External:R CORP\13.G__Team_Member:R And here is the directory with the permission denied problem $ cacls 'x:\02_0024\PPP\QQQ' x:\02_0024\PPP\QQQ CORP\13.G__Mgmt_Team:(DENY)(special access:) DELETE SYNCHRONIZE CORP\13.G__R_D_ITS:(DENY)(special access:) DELETE SYNCHRONIZE CORP\13.G__R_D_Restricted:(DENY)(special access:) DELETE SYNCHRONIZE CORP\13.G__RALM_Restricted:(DENY)(special access:) DELETE SYNCHRONIZE CORP\13.G__SCS_Restricted:(DENY)(special access:) DELETE SYNCHRONIZE CORP\13.G__Team_External:(DENY)(special access:) DELETE SYNCHRONIZE NT AUTHORITY\SYSTEM:(OI)(CI)F CORP\AllShareAdminGroup:(OI)(CI)F CORP\AllShareListGroup:(CI)R CORP\13.G__Access_Admin:(CI)R CORP\13.G__Team_Access_Admin:(CI)R CORP\16.0024_MO_Access_Admin:(CI)R CORP\13.G__Mgmt_Team:(OI)(CI)(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTES CORP\13.G__R_D_ITS:(OI)(CI)C CORP\13.G__R_D_Restricted:(OI)(CI)(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTES CORP\13.G__RALM_Restricted:(OI)(CI)(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTES CORP\13.G__SCS_Restricted:(OI)(CI)(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_WRITE FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTES CORP\13.G__Team_External:(OI)(CI)C CORP\13.G__Team_Member:(OI)(CI)(special access:) READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_DELETE_CHILD
Re: Fw: clear
Hello, when you search for ncurses in the Cygwin Package List of the cygwin.com website, two ncurses packages appear: - ncurses-5.5-2 - ncurses-5.5-3 However, neither of these packages in available in Setup.exe. Only libncurses libraries are available, and they are already installed on my computer. Philippe Brian Dessent [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/20/2007 11:48 AM Please respond to cygwin@cygwin.com To cygwin@cygwin.com cc Subject Re: Fw: clear [EMAIL PROTECTED] wrote: In Cygwin Package List, it says that clear was removed and that ncurses should be used instead (?). However, libncurses7 and libncurses8 ARE installed on my machine, according to setup.exe, which means, I guess, that ncurses is installed. No, it means that libncurses is installed. There is also a 'ncurses' package, and that is what contains the clear command. (You can look this up yourself using the Package Search page.) The reasoning for why packages are split like this has many reasons. For one thing, it allows library versioning, where you have multiple packages compiled against multiple versions of the library. For another, it allows installing just the binary runtime components of a library, without pulling in all the other nonessential parts just because the user happened to have installed a package that is linked against that library. And that is just what has happened in this case. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Copy/Paste doesn't run on Cygwin
On 20 August 2007 10:26, Jose Luis wrote: Hi, Without the .vimrc file the copy/paste runs fine in a vim's edited file, but when I copy the example vimrc file (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text isn't copy automatically on the clipboard. When the behaviour of vim changes in the presence of a .vimrc file, suspect something to do with the vi-compatible mode, which is disabled by doing so. Does adding '-C' to the command-line help? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fw: clear
[EMAIL PROTECTED] wrote: However, neither of these packages in available in Setup.exe. Only libncurses libraries are available, and they are already installed on my computer. They are available in setup. Set the view to Full for a flat list. If they're still not listed, then there must be something wrong with the mirror site that you've chosen. Brian -- 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: Copy/Paste doesn't run on Cygwin
Thanks for your help. I have tried it, but the problem persist. I have found som information about this issue on a Vim Forum: http://www.nabble.com/Patch-for-problems-with-X11-GUI---XTERM-clipboard-integration-with-native-Win-applications---was-%22clipboard-support-with-GTK-GUI-under-cygwin%22-tf935831.html#a2424350 Regards, Jose Luis Dave Korn wrote: On 20 August 2007 10:26, Jose Luis wrote: Hi, Without the .vimrc file the copy/paste runs fine in a vim's edited file, but when I copy the example vimrc file (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text isn't copy automatically on the clipboard. When the behaviour of vim changes in the presence of a .vimrc file, suspect something to do with the vi-compatible mode, which is disabled by doing so. Does adding '-C' to the command-line help? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12233308 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Line info causes GCC to bomb?
On 20 August 2007 10:54, g6522c wrote:
[ List Cc'd back in. http://cygwin.com/acronyms#PPIOSPE, thanks! ]
This preprocessed input causes GCC (3.4.4) to segfault
# 1 test.c 1
int main () {
return 0;
}
... and this doesn't:
# 1 test.c
# 1 test.c 1
int main () {
return 0;
}
This is from a different front end that I've put together. It's referred
to in the sig line. The line numbering is as documented - partially - in
the cpp Texinfo manual. The input seems to be valid for all other builds
of GCC.
I can't find that syntax described in the documentation, can point me at it?
I note that gcc doesn't generate code like your first form, it always does it
the second way, which makes me think that the first #-directive, the one
without the trailing number, acts as some kind of introducer or otherwise
triggers some internal struct to be set up in cpp without which the second
form, with the trailing number, is invalid.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Copy/Paste doesn't run on Cygwin
Here there is another link about this issue: http://www.nabble.com/Serious-flaw-in-Cygwin-X-clipboard-integration-prevents-paste-from-X-to-Windows-apps-tf946678.html#a2458589 It seems that it is a Cygwin X bug. Does anybody know if there is a fix to this problem? Regards, Jose Luis. Jose Luis wrote: Thanks for your help. I have tried it, but the problem persist. I have found som information about this issue on a Vim Forum: http://www.nabble.com/Patch-for-problems-with-X11-GUI---XTERM-clipboard-integration-with-native-Win-applications---was-%22clipboard-support-with-GTK-GUI-under-cygwin%22-tf935831.html#a2424350 Regards, Jose Luis Dave Korn wrote: On 20 August 2007 10:26, Jose Luis wrote: Hi, Without the .vimrc file the copy/paste runs fine in a vim's edited file, but when I copy the example vimrc file (/usr/share/vim/vim71/vimrc_example.vim) in $HOME/.vimrc, the selected text isn't copy automatically on the clipboard. When the behaviour of vim changes in the presence of a .vimrc file, suspect something to do with the vi-compatible mode, which is disabled by doing so. Does adding '-C' to the command-line help? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/Copy-Paste-doesn%27t-run-on-Cygwin-tf4297657.html#a12233534 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Line info causes GCC to bomb?
-Original Message-
From: Dave Korn [EMAIL PROTECTED]
Sent: Aug 20, 2007 6:25 AM
To: [EMAIL PROTECTED]
Cc: cygwin@cygwin.com
Subject: RE: Line info causes GCC to bomb?
On 20 August 2007 10:54, g6522c wrote:
[ List Cc'd back in. http://cygwin.com/acronyms#PPIOSPE, thanks! ]
This preprocessed input causes GCC (3.4.4) to segfault
# 1 test.c 1
int main () {
return 0;
}
... and this doesn't:
# 1 test.c
# 1 test.c 1
int main () {
return 0;
}
This is from a different front end that I've put together. It's referred
to in the sig line. The line numbering is as documented - partially - in
the cpp Texinfo manual. The input seems to be valid for all other builds
of GCC.
I can't find that syntax described in the documentation, can point me at it?
I note that gcc doesn't generate code like your first form, it always does
it the second way, which makes me think that the first #-directive, the one
without the trailing number, acts as some kind of introducer or otherwise
triggers some internal struct to be set up in cpp without which the second
form, with the trailing number, is invalid.
cheers,
DaveK
It's indexed in cpp.info under, linemarkers.
The output from cpp also contains other directives between the first two line
markers, as in the second form, although I haven't had the opportunity to look
at the gcc source to determine their purpose, or what initialization gcc needs
for its line numbering.
If I can locate the relevant routines in gcc I might be able to provide a
patch. My own preprocessor already has the necessary compatibility fix, though
untested, because my linux box is waiting for spare parts.
Thanks again,
Robert
Ctalk Project Home Page: http://ctalk-lang.sourceforge.net
Mailing List: [EMAIL PROTECTED]
--
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: Line info causes GCC to bomb?
[EMAIL PROTECTED] wrote: If I can locate the relevant routines in gcc I might be able to provide a patch. My I wouldn't spend too much effort on that. It's fixed in 4.x, and the 3.x branches were closed a long time ago. OTOH, it might be nice to have this fixed in the Cygwin-distributed gcc; however since it seems to be a rather esoteric corner case it's not a huge priority. Brian -- 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 compliation crash when uninstalling the old version of bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to wei on 8/19/2007 3:09 PM: Hi Eric It's a popup box from setup.exe. I also attached the cygcheck.out in the email And what did the popup say? Nothing in your cygcheck output is jumping out at me as unusual, but without knowing what the crash said, I don't know the full picture. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyYQT84KuGfSFAYARAuZnAKDCdEeaC4EZMnY5LYZzq6oONIRvyQCdEuaF cd5ZAyq6VoAJ2DRZOzxtcNs= =6zGw -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Default group shown by mkpasswd
Currently I have installed cygwin on two xp professional machines which behave slightly different. The problem is basically how to change my default group which is currently set in one machine to 513(None) and 547(Power Users) on the newer machine; as far as I found out yesterday, cygwin seems to have a special group whereas windows seems to ignore those. It would be very very great if one could either point me to a package which gives commands equal groupmod/add/del or if you can point me to a some site changing this behaviour. Thanks in advance SE -- 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: python module patch
On Sun, Aug 19, 2007 at 11:46:27AM +0200, Reini Urban wrote: Yaakov (Cygwin Ports) schrieb: Reini Urban wrote: extern __declspec(dllexport) cannot be used as constant during compile-time. = initializer element is not constant cygwin auto-import feature get's that right at link-time. This is needed for the constant (compile-time) resolution of PyObject_HEAD_INIT(PyType_Type) in a typical PyTypeObject struct. I believe the commonly accepted solution is to change this to PyObject_HEAD_INIT(NULL) in the struct. http://starship.python.net/crew/mwh/toext/node20.html Indeed. That sounds better. FWIW, I concur too. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: REAL Problem building GCC on Cygwin on Vista
On 19 August 2007 20:22, Aaron Gray wrote: Now I having a problem with libcpp getting the error :- checking dependancy style of gcc... /usr/src/gcc-4.2.0/libcpp/configure: line 2887: ./depcomp: premission denied. AFACT this actually looks like a Vista problem. I replaced line 2875 with :- cat $am_depcomp conftest.dir/depcomp from cp $am_depcomp conftest.dir It works fine now with the cat. Can someone look into this please, Aaron -- 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: Line info causes GCC to bomb?
On , Dave Korn dave.korn wrote:
[ Please try to snip rawquotes of email addresses from replies (or even
better, configure your mailer to snip em out), posting someone's address to
the list causes them to receive more spam.
(http://cygwin.com/acronyms#PCYMTNQREAIYR) ]
This preprocessed input causes GCC (3.4.4) to segfault
# 1 test.c 1
int main () {
return 0;
}
... and this doesn't:
# 1 test.c
# 1 test.c 1
int main () {
return 0;
}
I can't find that syntax described in the documentation, can point me at
it?
It's indexed in cpp.info under, linemarkers.
Ah, found it. Heh, so it's not documented in the section about Line
control, it's implicitly documented in the output format section.
The output from cpp also contains other directives between the first two
line markers, as in the second form, although I haven't had the opportunity
to look at the gcc source to determine their purpose, or what
initialization gcc needs for its line numbering.
If I can locate the relevant routines in gcc I might be able to provide a
patch. My own preprocessor already has the necessary compatibility fix,
though untested, because my linux box is waiting for spare parts.
shrugsIt's an arguable case. These pseudo-line-directives are part of
the internal interface between parts of the compiler and I think not really
intended for general consumption, even though it is described as an
extension. Since the form with the file introducer is what gcc generates,
and is what is guaranteed to work across all versions, I think you should
treat this situation as if there is a documentation error in the cpp manual,
and that it's part of the spec that you need to have an introducer line
before any lines with flags.
As for the sources, that's gcc-3.4.4/gcc/cpp*.[ch] for the most part.
cheers,
DaveK
--
Can't think of a witty .sigline today
On 20 August 2007 12:26, g6522c wrote:
--
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: REAL Problem building GCC on Cygwin on Vista
On 20 August 2007 15:49, Aaron Gray wrote: On 19 August 2007 20:22, Aaron Gray wrote: Now I having a problem with libcpp getting the error :- checking dependancy style of gcc... /usr/src/gcc-4.2.0/libcpp/configure: line 2887: ./depcomp: premission denied. AFACT this actually looks like a Vista problem. I replaced line 2875 with :- cat $am_depcomp conftest.dir/depcomp from cp $am_depcomp conftest.dir It works fine now with the cat. Hm, that sounds like a file that you have write but not delete permissions to. Can someone look into this please, Well, just to state the obvious, /you/ would be the most ideally-placed person to do so. I don't even have Vista, so I'm kinda ruled out there, but I'd take a look at the perms and ACLs of conftest.dir and the existing depcomp file in there, using both 'getfacl' to show cygwin's view of the posix-style perms, and 'cacls' to compare with windoze's opinion. BTW, you didn't by any chance use winzip to unpack the tarball did you? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Line info causes GCC to bomb?
On 20 August 2007 12:40, Brian Dessent wrote: g6522c wrote: If I can locate the relevant routines in gcc I might be able to provide a patch. My I wouldn't spend too much effort on that. It's fixed in 4.x, and the 3.x branches were closed a long time ago. OTOH, it might be nice to have this fixed in the Cygwin-distributed gcc; however since it seems to be a rather esoteric corner case it's not a huge priority. It's not that likely that I'll spin any more cygwin 3.x releases, unless there's huge demand for it or some bug crops up that impacts a lot of people in everyday use, but please do Cc me if you generate any patch, because it might just happen. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: REAL Problem building GCC on Cygwin on Vista
On Aug 20 16:20, Dave Korn wrote: On 20 August 2007 15:49, Aaron Gray wrote: On 19 August 2007 20:22, Aaron Gray wrote: AFACT this actually looks like a Vista problem. [...] Hm, that sounds like a file that you have write but not delete permissions to. Can someone look into this please, Well, just to state the obvious, /you/ would be the most ideally-placed person to do so. I don't even have Vista, so I'm kinda ruled out there, but I'd take a look at the perms and ACLs of conftest.dir and the existing depcomp file in there, using both 'getfacl' to show cygwin's view of the posix-style perms, and 'cacls' to compare with windoze's opinion. BTW, you didn't by any chance use winzip to unpack the tarball did you? Apart from that, the file permission settings are the same in Vista compared to older OSes. The exception is the UAC stuff which could result in some executables having less permissions than usual, if, for instance, Internet Explorer has been used to download the executable. We can hopefully rule this out here, so it's just some permission problem which has nothing to do with the base OS. Note: Not all problems on Vista are Vista's (or, FWIW, Cygwin's) fault. See, for example http://cygwin.com/acronyms/#PEBCAK for one possible explanation of the problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: permissions/owners seen on cygwin-client vs. server
On Fri, 17 Aug 2007, Linda Walsh wrote: Corinna Vinschen wrote: Larry is right, of course, but I make a wild guess, nevertheless: CYGWIN=nosmbntsec --- Assuming you mean having that string in the CYGWIN env var, unfortunately, this is not the case. See http://cygwin.com/cygwin-ug-net/using-cygwinenv.html -- nosmbntsec is the default. You need to turn it on to get ntsec functionality on remote drives. As for including cygcheck, I don't have a problem doing that when necessary, but I prefer to check that it's not some braino, or that it is a real problem before attaching a full cygdump. How will we know if it's a real problem unless you include the cygcheck output? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-'old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: rsync problems from Vista installed cygwin, ok on XP
On Mon, 20 Aug 2007, DaveB wrote: Corinna Vinschen-2 wrote: On Aug 18 21:06, DaveB wrote: So... two interesting followon points... 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in the first place when I created this little test area in Vista? After all, I The directory has been created using native Windows tools. The permissions given using native Windows tools *are* strange and don't follow POSIX rules. It's perfectly valid that you can access a directory under Windows but get 000 POSIX permissions. You did see the '+' at the end of the permission in ls -l? OK, I now see this + and had no idea what it meant... but have now found the doc in cygwin by typing info ls, where it says... Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. For a file with an extended access control list, a `+' character is listed. Basic access control lists are equivalent to the permissions listed, and are not considered an alternate access method. Interesting. So if it knows there is an ACL which overrides the -- permissions that were inherited from C:\ then why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files... even if it cannot directly read the ACL maybe it could allow you to invoke some special rsync permissions sync'ing flag? I looked in the man rsync doc, and found some flags that might be helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite let you do automatically what would make sense, which is to create rsync'd files with rwx for the exe's and rw for the others. Not sure what the best way out of here is...??? I'm beginning to understand this a bit better, but it sure is a minefield... will generate ongoing problems for innocent future users. You misunderstand your problem. The problem is not that rsync on the source side cannot read the files (it can, since the ACLs allow it to). The problem is that the rsync on the destination side copies only the Unix permission bits from the source side (which are 000), and then it is unable to write to that directory (because the permissions are 000). What you want is some way of getting rsync to not copy permissions, or making rsync ACL-aware. I don't know of any way to do either, but then, I haven't used rsync extensively. Perhaps the documentation holds the answer. PS Can anyone point to a good article on ACL that explains the relationship to these ls -l permissions also? I'm sure MSDN has a lot of info on ACLs in general and on their use in Windows. If you want to know specifically how Cygwin maps ACLs to Unix permission bits, see http://cygwin.com/cygwin-ug-net/ntsec.html. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: permissions/owners seen on cygwin-client vs. server
On Mon, Aug 20, 2007 at 12:11:56PM -0400, Igor Peshansky wrote: On Fri, 17 Aug 2007, Linda Walsh wrote: As for including cygcheck, I don't have a problem doing that when necessary, but I prefer to check that it's not some braino, or that it is a real problem before attaching a full cygdump. How will we know if it's a real problem unless you include the cygcheck output? Right. There is no harm in including it and, since it is more than likely that we'd need it, including it eliminates one information-free cycle of email. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: REAL Problem building GCC on Cygwin on Vista
On Aug 20 16:20, Dave Korn wrote: On 20 August 2007 15:49, Aaron Gray wrote: On 19 August 2007 20:22, Aaron Gray wrote: AFACT this actually looks like a Vista problem. [...] Hm, that sounds like a file that you have write but not delete permissions to. Can someone look into this please, Well, just to state the obvious, /you/ would be the most ideally-placed person to do so. I don't even have Vista, so I'm kinda ruled out there, but I'd take a look at the perms and ACLs of conftest.dir and the existing depcomp file in there, using both 'getfacl' to show cygwin's view of the posix-style perms, and 'cacls' to compare with windoze's opinion. BTW, you didn't by any chance use winzip to unpack the tarball did you? No. Apart from that, the file permission settings are the same in Vista compared to older OSes. The exception is the UAC stuff which could result in some executables having less permissions than usual, if, for instance, Internet Explorer has been used to download the executable. We can hopefully rule this out here, so it's just some permission problem which has nothing to do with the base OS. Works fine on XP. The only things that are diferent are the Cygwin instillation and Vista. Note: Not all problems on Vista are Vista's (or, FWIW, Cygwin's) fault. See, for example http://cygwin.com/acronyms/#PEBCAK for one possible explanation of the problem. Nice reply :) Does look like a case of PEBCAK. Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on Vista though, XP is okay. So must be something to do with permissions. Aaron -- 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: REAL Problem building GCC on Cygwin on Vista
On 20 August 2007 17:42, Aaron Gray wrote: On Aug 20 16:20, Dave Korn wrote: BTW, you didn't by any chance use winzip to unpack the tarball did you? No. Just checking. Windoze tools don't generally do the right thing for cygwin's emulation of posix perms. Apart from that, the file permission settings are the same in Vista compared to older OSes. The exception is the UAC stuff which could result in some executables having less permissions than usual, if, for instance, Internet Explorer has been used to download the executable. We can hopefully rule this out here, so it's just some permission problem which has nothing to do with the base OS. I want to throw an AYS in Corinna's general direction here... one of the ongoing problems in 'doze security since wy back when is that the default perms for user-created files, the equivalent of the default umask under posix, have always been pretty wide open: AYS they haven't been tightened up for Vista? Works fine on XP. The only things that are diferent are the Cygwin instillation and Vista. Heh, so that's a bit like saying The only things that are different are everything, apart from the gcc source code. Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on Vista though, XP is okay. So must be something to do with permissions. So, what tool did you use to 'modify' it? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem building GCC on Cygwin on Vista
On 20 August 2007 17:42, Aaron Gray wrote: On Aug 20 16:20, Dave Korn wrote: BTW, you didn't by any chance use winzip to unpack the tarball did you? No. Just checking. Windoze tools don't generally do the right thing for cygwin's emulation of posix perms. Apart from that, the file permission settings are the same in Vista compared to older OSes. The exception is the UAC stuff which could result in some executables having less permissions than usual, if, for instance, Internet Explorer has been used to download the executable. We can hopefully rule this out here, so it's just some permission problem which has nothing to do with the base OS. I want to throw an AYS in Corinna's general direction here... one of the ongoing problems in 'doze security since wy back when is that the default perms for user-created files, the equivalent of the default umask under posix, have always been pretty wide open: AYS they haven't been tightened up for Vista? Works fine on XP. The only things that are diferent are the Cygwin instillation and Vista. Heh, so that's a bit like saying The only things that are different are everything, apart from the gcc source code. Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on Vista though, XP is okay. So must be something to do with permissions. So, what tool did you use to 'modify' it? A Windows text editor called Zeus. I have been altering the C source code and some configureation and gcc/makefile but AFAICT nothing that should effect gcc/configure though. Its all very odd. Hopefully I shall get to the bottom of it if I perservere, but any help or suggestions are welcome. Aaron -- 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: Problem building GCC on Cygwin on Vista
On 20 August 2007 18:16, Aaron Gray wrote: Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on Vista though, XP is okay. So must be something to do with permissions. So, what tool did you use to 'modify' it? A Windows text editor called Zeus. I have been altering the C source code and some configureation and gcc/makefile but AFAICT nothing that should effect gcc/configure though. Its all very odd. Hopefully I shall get to the bottom of it if I perservere, but any help or suggestions are welcome. Well, why don't you actually *look* at those perms, instead of asking people who have no access to your computer and no idea what you've been doing to make random guesses? All your descriptions are way too vague for any attempt at remote diagnosis. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem building GCC on Cygwin on Vista
On 20 August 2007 18:16, Aaron Gray wrote: Unmodified GCC 4.2.0 compiles okay, but when modified cracks appear, only on Vista though, XP is okay. So must be something to do with permissions. So, what tool did you use to 'modify' it? A Windows text editor called Zeus. I have been altering the C source code and some configureation and gcc/makefile but AFAICT nothing that should effect gcc/configure though. Its all very odd. Hopefully I shall get to the bottom of it if I perservere, but any help or suggestions are welcome. Well, why don't you actually *look* at those perms, instead of asking people who have no access to your computer and no idea what you've been doing to make random guesses? All your descriptions are way too vague for any attempt at remote diagnosis. Sorry I will have a look but I am not very strong in this area. Aaron -- 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: Problem building GCC on Cygwin on Vista
On 20 August 2007 19:13, Aaron Gray wrote: On 20 August 2007 18:16, Aaron Gray wrote: Hopefully I shall get to the bottom of it if I perservere, but any help or suggestions are welcome. Well, why don't you actually *look* at those perms, instead of asking people who have no access to your computer and no idea what you've been doing to make random guesses? All your descriptions are way too vague for any attempt at remote diagnosis. Sorry I will have a look but I am not very strong in this area. Feel free to post the results of cacls and getfacl back here when you've got them, but until then, we're basically toiletless[*] in this matter. cheers, DaveK [*] - Y'know. Nothing to go on. -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem building GCC on Cygwin on Vista
Aaron Gray wrote: A Windows text editor called Zeus. That's it. I bet the problem disappears if you use a Cygwin text editor such as vim. When a native Windows app creates a file, it usually does not do anything special with the ACL, so it gets whatever the default inheritable permissions of the directory happen to be, which it looks like are not correct. You could also try a native editor that edits in-place instead of the usual create new file with temporary name then rename. Brian -- 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: Problem building GCC on Cygwin on Vista
Aaron Gray wrote: A Windows text editor called Zeus. That's it. I bet the problem disappears if you use a Cygwin text editor such as vim. When a native Windows app creates a file, it usually does not do anything special with the ACL, so it gets whatever the default inheritable permissions of the directory happen to be, which it looks like are not correct. You could also try a native editor that edits in-place instead of the usual create new file with temporary name then rename. Except its not a file I have editted that is causing the problem, they are all behaving fine. Things are a bit slow at this end due to other tasks and I am running out of time before I am back home away from my Vista machine at my parents so this may have to be put on hold as getting back to the original problem place is taking longer than I though and producing meaning full results from examining source will take a while. Hopefully I will have some results soon... Aaron -- 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: Problem building GCC on Cygwin on Vista
Okay I printed out '$am_depcomp' which was effectivly 'gcc4.2.0/libcpp/../depcomp' and put an 'exit' at (effective) line 2888 and the file gcc4.2.0/depcomp does not seem to exist. Very strange as I found 'depcomp' before previously and its printing 'line: 2888: ./depcomp: permisssion denied' rather than 'file not found' still. Is this just another missing Cygin package again ? Aaron -- 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: Problem building GCC on Cygwin on Vista
Ignore the previous post depcomp is under src/gcc-4.2.0 not build/gcc-4.2.0 ! Sorry to mess you about. I'll get some ACL results now ... Aaron -- 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: Problem building GCC on Cygwin on Vista
Okay getfacl is reporting 'user::---' rather than 'user::rwx' for depcomp on my patched version of GCC. This leads to two questions ... How do I modify this to be correct ? Why is it different from gcc-4.2.0's ? Thanks for bearing with me. Aaron -- 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: Problem building GCC on Cygwin on Vista
Why is it different from gcc-4.2.0's ? Okay I am kicking myself now many hours wasted it was because I used a Windows program WinRAR to unpack my work rather than using tar !!! It was a permissions problem afterall. Very sorry for poluting your mailing list. Regards, Aaron -- 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/
Latest mutt (1.4.2.2-1) does not work on (my) XP
Hello. I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every operation I try to do I get an error like 'cannot create temporary file'. It's not a permission problem... files are created (even tried different temp dirs) with 0 size. Reverting to version 1.4.2.1i-1 everything works. I don't know what changed, but the main binary of 1.4.2.1i-1 has 539136 bytes and 1.4.2.2-1 has 1554944 bytes (3 times more). Tips appreciated. Thanks -- Pedro Alves -- 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: Latest mutt (1.4.2.2-1) does not work on (my) XP
On Mon, Aug 20, 2007 at 10:57:52PM +0100, Pedro Alves wrote: I can't run latest mutt, version mutt-1.4.2.2-1 on my XP. For every operation I try to do I get an error like 'cannot create temporary file'. It's not a permission problem... files are created (even tried different temp dirs) with 0 size. What does tried different temp dirs mean? How did you try them? By setting an environment variable. Please provide a *specific* operation that does not work. Tips appreciated. Ditto. vv Problem reports: http://cygwin.com/problems.html ^^ cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest mutt (1.4.2.2-1) does not work on (my) XP
On Mon, Aug 20, 2007 at 06:21:38PM -0400, Christopher Faylor wrote: What does tried different temp dirs mean? How did you try them? By setting an environment variable. editing ~/.muttrc's tmpdir property Please provide a *specific* operation that does not work. The simplest one, pressing '?' for help. Also, pressing enter to see a message does not work, always returns the same error and a file with size 0 is created in the temp dir gwin.com/faq/ -- Pedro Alves -- 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: Latest mutt (1.4.2.2-1) does not work on (my) XP
On Mon, Aug 20, 2007 at 11:35:37PM +0100, Pedro Alves wrote: On Mon, Aug 20, 2007 at 06:21:38PM -0400, Christopher Faylor wrote: What does tried different temp dirs mean? How did you try them? By setting an environment variable. editing ~/.muttrc's tmpdir property Please provide a *specific* operation that does not work. The simplest one, pressing '?' for help. Also, pressing enter to see a message does not work, always returns the same error and a file with size 0 is created in the temp dir Sorry but WJFFM. vv Problem reports: http://cygwin.com/problems.html ^^ cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
symbolic link untar issue
These steps 'hide bash', so invoking bash again fails: /tmp $ uname -a CYGWIN_NT-5.0 argon 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin /tmp $ tar tvf bar.tar drwxrwxr-x staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/ lrwxrwxrwx staffuser1/XYZ_ES_STAFF 0 2007-08-20 17:29 ZZ/bash2 - /bin/bash /tmp $ tar xpf bar.tar; tar xpf bar.tar #2nd untar does the damage /tmp $ ls -l /bin/bash -- 1 adm_usr1 None 0 Aug 20 18:03 /bin/bash /tmp $ ls -l /bin/bash.exe -rwxrwxrwx 1 Administrator Users 470528 May 1 21:22 /bin/bash.exe* /tmp $ bash -bash: /usr/bin/bash: Permission denied Notice the zero byte file '/bin/bash' w/o any perms; it causes subsequent invocations of bash to fail. It is the 2nd untar that does it. Here's what is in 'bar.tar' ( which is also attached ): /tmp/ZZ $ md5sum /tmp/bar.tar 0a3b22f3e6d00c68f7000b4fc1b80993 */tmp/bar.tar /tmp $ cd ZZ /tmp/ZZ $ cmd /c dir Volume in drive D has no label. Volume Serial Number is BC28-E542 Directory of d:\aut\cyg\tmp\ZZ 08/20/2007 05:29p DIR . 08/20/2007 05:29p DIR .. 08/20/2007 06:03p 108 bash2.lnk 1 File(s)108 bytes 2 Dir(s) 544,944,128 bytes free /tmp/ZZ $ cmd /c type bash2.lnk|command od -Ad -c 000 L \0 \0 \0 001 024 002 \0 \0 \0 \0 \0 300 \0 \0 \0 016 \0 \0 \0 F \f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 032 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 048 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 064 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \t \0 / b 080 i n / b a s h 023 \0 d : \ a u t \ 096 c y g \ b i n \ b a s h 108 Is that an old style cygwin snybolic link? If so how do I identify all of them, so I might update them on my system? -- thanks, Tom Rodman -- Cleanup.., how to delete the zero byte '/bin/bash': /tmp/ZZ $ (cd /bin ; chmod 777 bash;cmd /c del bash; ls -l bash) -rwxrwxrwx 1 Administrator Users 470528 May 1 21:22 bash* -- bar.tar.gz Description: Binary data -- 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: Problem detecting subprocess termination after _spawn_posix in distutils?
Steve Holden wrote: Martin v. Löwis wrote: The only environment variables that don't appear in the shell output from the env command are INFOPATH, MAKE_MODE and PLAT. I am still flummoxed. At this point, I'd recommend to perform a cygwin update; with Cygwin, these problems often go away with an update. I updated Cygwin and did a rebaseall before posting. If that doesn't help, you can ask on the Cygwin list also; to analyse this further, ISTM one will need to debug the internals of cygwin. I posted on Cygwin before asking here. One thing you could try is to add -v to the list of gcc options; you can then see whether gcc is progressing correctly. I'll do that, though I have reason to believe the gcc *is* terminating and _spawn_posix isn't detecting the end of the process. At the very least we should get another test out of this dreadfully irritating bug. Thanks again for looking at this. A further data point (sorry, I've not had a lot of time to look at this). Building Python from the trunk at rev 57076 yielded a system that *would* cleanly build the same release of PIL. This is somewhat annoying because it appears to put the bug in the past where there's less incentive to investigate it. But I may find time to take a look. Hardly worth it if I'm the only one noticing the issue, though. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- 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: rsync problems from Vista installed cygwin, ok on XP
Igor Peshansky wrote: On Mon, 20 Aug 2007, DaveB wrote: Corinna Vinschen-2 wrote: On Aug 18 21:06, DaveB wrote: So... two interesting followon points... 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in the first place when I created this little test area in Vista? After all, I The directory has been created using native Windows tools. The permissions given using native Windows tools *are* strange and don't follow POSIX rules. It's perfectly valid that you can access a directory under Windows but get 000 POSIX permissions. You did see the '+' at the end of the permission in ls -l? OK, I now see this + and had no idea what it meant... but have now found the doc in cygwin by typing info ls, where it says... Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. For a file with an extended access control list, a `+' character is listed. Basic access control lists are equivalent to the permissions listed, and are not considered an alternate access method. Interesting. So if it knows there is an ACL which overrides the -- permissions that were inherited from C:\ then why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files... even if it cannot directly read the ACL maybe it could allow you to invoke some special rsync permissions sync'ing flag? I looked in the man rsync doc, and found some flags that might be helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite let you do automatically what would make sense, which is to create rsync'd files with rwx for the exe's and rw for the others. Not sure what the best way out of here is...??? I'm beginning to understand this a bit better, but it sure is a minefield... will generate ongoing problems for innocent future users. You misunderstand your problem. The problem is not that rsync on the source side cannot read the files (it can, since the ACLs allow it to). The problem is that the rsync on the destination side copies only the Unix permission bits from the source side (which are 000), and then it is unable to write to that directory (because the permissions are 000). What you want is some way of getting rsync to not copy permissions, or making rsync ACL-aware. I don't know of any way to do either, but then, I haven't used rsync extensively. Perhaps the documentation holds the answer. PS Can anyone point to a good article on ACL that explains the relationship to these ls -l permissions also? I'm sure MSDN has a lot of info on ACLs in general and on their use in Windows. If you want to know specifically how Cygwin maps ACLs to Unix permission bits, see http://cygwin.com/cygwin-ug-net/ntsec.html. Igor Don't think I misunderstood... what I was saying above agrees with you - the ACLs allow cygwin/rsync to read the files, but it then proceeds to transfer the posix permissions, which are 000. The ntsec article above is very helpful actually, explaining the problem more clearly - there is a mismatch between posix and NT security. cygwin is an environment trying to bridge the gap. It seems that a good solution might be to provide a cygwin environment variable which ORs the read/write access of the current user with the posix flags right from the start... Then even an ls -l would come up with rwx where applicable (instead of --- at the moment), and programs like cygwin/rsync would then behave themselves and cause less of a surprise to the end user. My earlier comment said why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files If there was a Windows friendly env variable that made current ACL the default reported security setting for the rwx flag (at least for the owner) then there would be no need to fiddle with anything in rsync, fix the problem upstream. Cygwin does things like this in other areas - eg it provides env variables for dealing better with the case dependence in filenames which is fundamentally different between unix and Windows. So why not make it behave more like Windows in the security area? Until it was pointed out to me what was going on here, I was oblivious to the --- posix setting and happily reading and writing files in this directory in Windows, so of course it was a surprise when rsync's copy of the directory to a unix system zapped the rwx setting of the directory copy up there. As Igor is saying, this is the underlying problem... The problem is not that rsync on the source side cannot read the files (it can, since the ACLs allow it to). The problem is that the rsync on the destination side copies only the Unix permission
Re: Line info causes GCC to bomb?
-Original Message- From: Brian Dessent [EMAIL PROTECTED] Sent: Aug 20, 2007 7:40 AM To: cygwin@cygwin.com I wouldn't spend too much effort on that. It's fixed in 4.x, and the 3.x branches were closed a long time ago. OTOH, it might be nice to have this fixed in the Cygwin-distributed gcc; however since it seems to be a rather esoteric corner case it's not a huge priority. I mostly wanted to dutifully note the issue. As I indicated, it's easy to work around for me, and if someone decides to upgrade the Cygwin package they might need to be aware of it. Thanks again, Robert Ctalk Project Home Page: http://ctalk-lang.sourceforge.net Mailing List: [EMAIL PROTECTED] -- 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 compliation crash when uninstalling the old version of bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please keep replies on the list - http://cygwin.com/acronyms/#PPIOSPE According to wei on 8/20/2007 12:16 PM: Hi Eric And what did the popup say? Nothing in your cygcheck output is jumping out at me as unusual, but without knowing what the crash said, I don't know the full picture. I just recompiled the cygwin from scratch after delete the previous directory to bypass the problem. You still didn't describe the problem, but I'm glad you seem to have resolved this. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyjyf84KuGfSFAYARAi/ZAKClqI+VWH1/kII92ZaUe00rBRHBEQCg0vbV NxypnUpNPYxmj8HUoGrg3W4= =p1+h -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How to close a SSH connection from a BAT file
Anthony de Sousa adesousa at csc.com writes: I would like to conclude that we have decided to use AUTOSSH to control ssh. With autossh the processes are stoped automatically whenever autossh is stoped. As Brian originally suggested all that is then required on either side of the bat file is a Net Start Autossh and a Net Stop Autossh. Many Thanks -- 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/
