Re: Suggestion for terminal package maintainers
On Jun 2 17:47, Corinna Vinschen wrote: On Jun 2 11:39, Christopher Faylor wrote: On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote: Maybe it is, that's why I'm asking. But, if we do that, shouldn't Ctrl-Backspace return ^H as in xterm? So far the Cygwin console returned ^H without and ^? with Ctrl, now it returns ^? in both variations. IMO, cygwin's console == linux console. On two of my systems (Fedora and Gentoo) CTRL-Backspace returns Backspace on the console. Now that I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system. But, so far, the CTRL-Backspace == Backspace contingent is winning. Uh, oh, hmm. I was always under the impression we try to be as xterm compatible as possible, rather than the Linux console. I found a problem with this change. Tcsh's default keybinding for ^? is backward-delete-word, while ^H is bound to backward-delete-char. So far it was possible to use Alt-Backspace to delete a word. This doesn't work anymore since ^? is now mapped to backward-delete-char due to the tty erase being set to ^?, and Alt-Backspace only returning a NUL byte. Using Alt-Backspace to delete a word works fine in the Linux console. This means, the keymapping for Alt-Backspace does not return ^? but one of the other character sequences bound to backward-delete-word: tcsh$ bindkey | grep backward-delete-word ^W - backward-delete-word \210 - backward-delete-word \377 - backward-delete-word ^[^H - backward-delete-word ^[^? - backward-delete-word The problem is, for some reason the sequence generated by Alt-Backspace is not visible in od output. Neither for the Linux console, nor in xterm. Does anybody know the sequence? I failed to figure that out via google. Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. That's how the META key is usually defined and it brings back the old Alt-Backspace functionality to tcsh. I checked my change in for now. If somebody thinks it's wrong and has another solution, just speak up. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Suggestion for terminal package maintainers
On 6/3/2009 7:09 AM, Corinna Vinschen wrote: On Jun 2 17:47, Corinna Vinschen wrote: On Jun 2 11:39, Christopher Faylor wrote: On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote: Maybe it is, that's why I'm asking. But, if we do that, shouldn't Ctrl-Backspace return ^H as in xterm? So far the Cygwin console returned ^H without and ^? with Ctrl, now it returns ^? in both variations. IMO, cygwin's console == linux console. On two of my systems (Fedora and Gentoo) CTRL-Backspace returns Backspace on the console. Now that I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system. But, so far, the CTRL-Backspace == Backspace contingent is winning. Uh, oh, hmm. I was always under the impression we try to be as xterm compatible as possible, rather than the Linux console. I found a problem with this change. Tcsh's default keybinding for ^? is backward-delete-word, while ^H is bound to backward-delete-char. So far it was possible to use Alt-Backspace to delete a word. This doesn't work anymore since ^? is now mapped to backward-delete-char due to the tty erase being set to ^?, and Alt-Backspace only returning a NUL byte. Using Alt-Backspace to delete a word works fine in the Linux console. This means, the keymapping for Alt-Backspace does not return ^? but one of the other character sequences bound to backward-delete-word: tcsh$ bindkey | grep backward-delete-word ^W - backward-delete-word \210 - backward-delete-word \377 - backward-delete-word ^[^H - backward-delete-word ^[^? - backward-delete-word The problem is, for some reason the sequence generated by Alt-Backspace is not visible in od output. Neither for the Linux console, nor in xterm. Does anybody know the sequence? I failed to figure that out via google. Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. That's how the META key is usually defined and it brings back the old Alt-Backspace functionality to tcsh. As long as you're changing the Cygwin console to be more compatible with linux and/or xterm, let me just mention that some key combinations involving the control key don't work in the Cygwin console the way they do in linux and xterm. Here are two specific examples I've noticed, but I haven't made an exhaustive search: 1. Control-space appears to generate space in the cygwin console. 2. Control-Alt-any key does not appear to generate anything (or maybe it generates NUL). Ken
Re: Suggestion for terminal package maintainers
2009/6/3 Corinna Vinschen: Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. I think that's the right thing to do. I'd pointed out the problem with Alt+Backspace, but that got lost in the discussion about my suggestion to have Ctrl+Backspace send ^_. The keycode probably doesn't show up in od output because the pseudo terminal device interprets the ^? for line editing purposes. Attached is a small program I use for echoing keycodes, which puts the terminal device into raw mode. Quit with ^D. Andy echokeys.c Description: Binary data
Re: Suggestion for terminal package maintainers
On Jun 3 08:03, Ken Brown wrote:
On 6/3/2009 7:09 AM, Corinna Vinschen wrote:
Even not knowing the sequence returned by Alt-Backspace, AFAICS, the
right thing to do is to send either ^[^? or \377, dependent on the
setting of dev_state-metabit. That's how the META key is usually
defined and it brings back the old Alt-Backspace functionality to tcsh.
As long as you're changing the Cygwin console to be more compatible with
linux and/or xterm, let me just mention that some key combinations
involving the control key don't work in the Cygwin console the way they
do in linux and xterm. Here are two specific examples I've noticed, but
I haven't made an exhaustive search:
1. Control-space appears to generate space in the cygwin console.
Right. That's because the space key does not return any other character
then 0x20 in the Windows console, regardless of the modifier keys you're
pressing. Same goes for Alt-Space which should ideally return Esc-Space
or \240. Maybe we should really add that while we're at it.
2. Control-Alt-any key does not appear to generate anything (or maybe
it generates NUL).
That's a longstanding problem which probably can't be fixed satisfingly.
On non-English keyboards, the right Alt key is called AltGr and returns
the modifiers Left-Control/Right-Alt. It's used to enter certain
characters which are not accessible using the normla keys with just the
shift modifier. For instance, on a german keyboard, the keys [/{ and
]/} are replaced with Umlaut-u and +/* keys. To enter the square and
curly braces, one has to type AltGr-7 up to AltGr-0. The problem is,
you can't distinguish between pressing Ctrl+Alt and pressing AltGr on
these keyboards (or rather, in these keyboard settings).
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: Suggestion for terminal package maintainers
On Jun 3 13:05, Andy Koppe wrote: The keycode probably doesn't show up in od output because the pseudo terminal device interprets the ^? for line editing purposes. Attached is a small program I use for echoing keycodes, which puts the terminal device into raw mode. Quit with ^D. Yep, that's it. It shows that my idea was correct. Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Suggestion for terminal package maintainers
On 6/3/2009 8:53 AM, Corinna Vinschen wrote:
On Jun 3 08:03, Ken Brown wrote:
1. Control-space appears to generate space in the cygwin console.
Right. That's because the space key does not return any other character
then 0x20 in the Windows console, regardless of the modifier keys you're
pressing. Same goes for Alt-Space which should ideally return Esc-Space
or \240. Maybe we should really add that while we're at it.
From my emacs-centric view of things, I think you should. Both
Alt-Space and Control-Space are used a lot in emacs, especially
Control-Space.
2. Control-Alt-any key does not appear to generate anything (or maybe
it generates NUL).
That's a longstanding problem which probably can't be fixed satisfingly.
On non-English keyboards, the right Alt key is called AltGr and returns
the modifiers Left-Control/Right-Alt. It's used to enter certain
characters which are not accessible using the normla keys with just the
shift modifier. For instance, on a german keyboard, the keys [/{ and
]/} are replaced with Umlaut-u and +/* keys. To enter the square and
curly braces, one has to type AltGr-7 up to AltGr-0. The problem is,
you can't distinguish between pressing Ctrl+Alt and pressing AltGr on
these keyboards (or rather, in these keyboard settings).
What do linux and xterm do? Ctrl+Alt is a commonly-used key combination
in emacs, so it would be surprising if they didn't work on a non-English
keyboard. But I've never had occasion to try it, and I don't have
access to a non-English keyboard right now. Maybe Andy knows the
answer. In mintty, can you distinguish between Ctrl+Alt and AltGr on a
non-English keyboard?
Ken
Re: Suggestion for terminal package maintainers
On 6/3/2009 8:53 AM, Corinna Vinschen wrote: On non-English keyboards, the right Alt key is called AltGr and returns the modifiers Left-Control/Right-Alt. So maybe the answer is that Left-Control+Left-Alt and Right-Control+Right-Alt should each be interpreted as Control+Alt. Someone deliberately trying to enter Control+Alt+some-other-key is not likely to use different hands for Control and Alt. I assume you have a German keyboard and could test whether my suggestion is consistent with the behavior of linux and xterm. Ken
Re: Suggestion for terminal package maintainers
On Jun 3 10:16, Ken Brown wrote: On 6/3/2009 8:53 AM, Corinna Vinschen wrote: On non-English keyboards, the right Alt key is called AltGr and returns the modifiers Left-Control/Right-Alt. So maybe the answer is that Left-Control+Left-Alt and Right-Control+Right-Alt should each be interpreted as Control+Alt. Someone deliberately trying to enter Control+Alt+some-other-key is not likely to use different hands for Control and Alt. Wrong, imho. If the non-modifier key is on the right side of the keyboard, many users tend to press left-ctrl/right-alt/non-mod-key. Trust me. We had kind of the same discussion 10 or so years ago. I assume you have a German keyboard and could test whether my suggestion is consistent with the behavior of linux and xterm. No, I have a US keyboard running only US systems. But it doesn't matter. You can simply change to another keyboard layout using the Windows Language Bar, after you have added the keyboard layout by using the Regional and Language Options control panel, independent from the language of the installed Windows. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Suggestion for terminal package maintainers
On 6/3/2009 10:32 AM, Corinna Vinschen wrote: On Jun 3 10:16, Ken Brown wrote: On 6/3/2009 8:53 AM, Corinna Vinschen wrote: On non-English keyboards, the right Alt key is called AltGr and returns the modifiers Left-Control/Right-Alt. So maybe the answer is that Left-Control+Left-Alt and Right-Control+Right-Alt should each be interpreted as Control+Alt. Someone deliberately trying to enter Control+Alt+some-other-key is not likely to use different hands for Control and Alt. Wrong, imho. If the non-modifier key is on the right side of the keyboard, many users tend to press left-ctrl/right-alt/non-mod-key. Trust me. We had kind of the same discussion 10 or so years ago. OK. I'm not interested in repeating an old discussion. But it does seem that the release of 1.7 is a good time to decide whether the cygwin console is emulating linux or xterm or something else and then make this happen as much as possible. FWIW, I just tried Andy's echokeys program in xterm and in mintty. In xterm the output is \x81 with all four combinations of left/right. In mintty, the output is ^[^A with three of the four combinations, and nothing in the fourth. The one that generates nothing is left-ctrl/right-alt (corresponding to AltGr). Ken
Re: Suggestion for terminal package maintainers
On 6/3/2009 10:52 AM, Ken Brown wrote: FWIW, I just tried Andy's echokeys program in xterm and in mintty. Sorry, I forgot to say that I pressed Ctrl+Alt+A, but you can see that from the output anyway. Ken
Re: Suggestion for terminal package maintainers
On 6/2/2009 9:28 AM, Ken Brown wrote: On 6/2/2009 8:48 AM, Corinna Vinschen wrote: On Jun 1 17:03, Ken Brown wrote: The Cygwin console, after some changes made this past weekend, now uses ^? as the default erase character, and this is what is sent by the backspace key instead of ^H [...] What makes me a bit concerned about this change is that, while we can change Cygwin's terminfo and termcap files, we can't do that for existing non-Cygwin installations. Is it really safe to change the BS key to ^? now that the cygwin terminal type is known to return ^H for so many years? Applications like emacs that use ncurses should have no problem. Are there applications that rely on the historical behavior of the cygwin terminal type rather than querying terminfo? Apart from cygwin, such applications would have problems with any terminal type that decides to change its behavior. Sorry, I think I misinterpreted what you meant by non-Cygwin installations. But wouldn't the issue be resolved by pushing the change to the cygwin terminal type in terminfo upstream? If it were about termcap/terminfo, it must be expected that an upstream change would take years until it propagates to most actual installations, which means years of inconsistent default configuration for remote login from cygwin console... On the other hand, with this specific setting, the dreadful backspace issue, it is more crucial that the setting of stty is consistent with what the terminal actually sends. So of course it needs to be made sure that this works within cygwin. - About remote login, it should be noted that Linux systems (some at least) as well as SunOS seem to be assuming stty ^? on remote login, which is obviously not proper behaviour (especially if termcap says something different), but that's what I see. So in that respect, typical configuration is not consistent right now and would become consistent by this change. 2009/6/2 Corinna Vinschen: On Jun 2 11:39, Christopher Faylor wrote: On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote: Maybe it is, that's why I'm asking. But, if we do that, shouldn't Ctrl-Backspace return ^H as in xterm? So far the Cygwin console returned ^H without and ^? with Ctrl, now it returns ^? in both variations. While it is true that the xterm resource backarrowKey would set this to ^H by default, most actual Linux installation change it by common configuration. IMO, cygwin's console == linux console. On two of my systems (Fedora and Gentoo) CTRL-Backspace returns Backspace on the console. Now that I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system. But, so far, the CTRL-Backspace == Backspace contingent is winning. Uh, oh, hmm. I was always under the impression we try to be as xterm compatible as possible, rather than the Linux console. Checking escape sequences of function keys and keypad keys, there are many similarities (and common deficiencies) with Linux console and some weird differences: * Linux console (SUSE, don't know if it's really consistent) defines function keys F1...F12 and Shift-F1...Shift-F8 (very weird to stop here). * Cygwin console Shift-F1 and Shift-F2 are identical to F11 and F12, I don't think that's intended, I guess it should also be changed on the occasion of revising the console. * Cygwin console has shifted function keys up to Shift-F10, no F11/F12. * No Control-/Alt-modified function keys (on either console). * No Control-/Shift-/Alt-modified keypad keys (i.e. cursor keys, Home etc); I would very much appreciate if this gets improved, too. * Cygwin console lacks one feature that is quite useful: cursor position reports. On output of ^[[6n, the terminal should respond an escape sequence encoding the current cursor position. 2009/6/3 Corinna Vinschen: Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. I think that's the right thing to do. I'd pointed out the problem with Alt+Backspace, but that got lost in the discussion about my suggestion to have Ctrl+Backspace send ^_. The keycode probably doesn't show up in od output because the pseudo terminal device interprets the ^? for line editing purposes. Not quite the pseudo terminal. It's the readline function (of bash, cat, ...) so obviously ^? rubs out the ESC again as it should. Attached is a small program I use for echoing keycodes, which puts the terminal device into raw mode. Quit with ^D. The following would also serve as a quick test: stty raw; od -t x1 By the way, I've always wondered why I cannot use cat for a quick test of most keyboard escape sequences in cygwin. This works quite nicely in Linux (except for the case above, apparently). On cygwin, entering cursor keys to cat just lets the cursor wander around, while on Linux it
Re: Suggestion for terminal package maintainers
On Wed, Jun 03, 2009 at 01:05:58PM +0100, Andy Koppe wrote: 2009/6/3 Corinna Vinschen: Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. I think that's the right thing to do. I'd pointed out the problem with Alt+Backspace, but that got lost in the discussion about my suggestion to have Ctrl+Backspace send ^_. It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. cgf
Re: Suggestion for terminal package maintainers
On Jun 3 11:57, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 01:05:58PM +0100, Andy Koppe wrote: 2009/6/3 Corinna Vinschen: Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. I think that's the right thing to do. I'd pointed out the problem with Alt+Backspace, but that got lost in the discussion about my suggestion to have Ctrl+Backspace send ^_. It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. It does. I just checked again and it returns ^[^?. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Suggestion for terminal package maintainers
On Wed, Jun 03, 2009 at 06:08:03PM +0200, Corinna Vinschen wrote: On Jun 3 11:57, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 01:05:58PM +0100, Andy Koppe wrote: 2009/6/3 Corinna Vinschen: Even not knowing the sequence returned by Alt-Backspace, AFAICS, the right thing to do is to send either ^[^? or \377, dependent on the setting of dev_state-metabit. I think that's the right thing to do. I'd pointed out the problem with Alt+Backspace, but that got lost in the discussion about my suggestion to have Ctrl+Backspace send ^_. It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. It does. I just checked again and it returns ^[^?. I wasn't claiming that you were mistaken about seeing something. However, I did try to emulate what I saw on my linux systems which is why the code carefully did nothing in the case of Alt-Backspace. cgf
Re: Suggestion for terminal package maintainers
On Jun 3 12:58, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 06:08:03PM +0200, Corinna Vinschen wrote: On Jun 3 11:57, Christopher Faylor wrote: It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. It does. I just checked again and it returns ^[^?. I wasn't claiming that you were mistaken about seeing something. However, I did try to emulate what I saw on my linux systems which is why the code carefully did nothing in the case of Alt-Backspace. Uh, I see. I already feared that might be different between the consoles of different Linux systems. Programming terminal emulation is a thankless job. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Suggestion for terminal package maintainers
On 6/3/2009 1:21 PM, Corinna Vinschen wrote: On Jun 3 12:58, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 06:08:03PM +0200, Corinna Vinschen wrote: On Jun 3 11:57, Christopher Faylor wrote: It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. It does. I just checked again and it returns ^[^?. I wasn't claiming that you were mistaken about seeing something. However, I did try to emulate what I saw on my linux systems which is why the code carefully did nothing in the case of Alt-Backspace. Uh, I see. I already feared that might be different between the consoles of different Linux systems. Is it really different, or does this comment from Thomas Wolff earlier in the thread explain the discrepancy? On 6/3/2009 11:23 AM, Thomas Wolff wrote: It's the readline function (of bash, cat, ...) so obviously ^? rubs out the ESC again as it should. Ken
Re: Suggestion for terminal package maintainers
On Wed, Jun 03, 2009 at 02:11:29PM -0400, Ken Brown wrote: On 6/3/2009 1:21 PM, Corinna Vinschen wrote: On Jun 3 12:58, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 06:08:03PM +0200, Corinna Vinschen wrote: On Jun 3 11:57, Christopher Faylor wrote: It didn't get lost. The message is the same. I implemented the behavior of backspace to match the way backspace worked on two different linux consoles. I've now checked a third linux console and Alt-Backspace doesn't do anything there either. It does. I just checked again and it returns ^[^?. I wasn't claiming that you were mistaken about seeing something. However, I did try to emulate what I saw on my linux systems which is why the code carefully did nothing in the case of Alt-Backspace. Uh, I see. I already feared that might be different between the consoles of different Linux systems. Is it really different, or does this comment from Thomas Wolff earlier in the thread explain the discrepancy? Ah, right. The old CTRL-V method doesn't work for two character sequences when the second one is ^?. Using stty raw shows that Alt-Backspace does return what Corinna says above, at least on Ubuntu. cgf
Re: Suggestion for terminal package maintainers
Ah, right. The old CTRL-V method doesn't work for two character sequences when the second one is ^?. Using stty raw shows that Alt-Backspace does return what Corinna says above, at least on Ubuntu. Same on Suse and Debian (well, Knoppix). Andy
Re: Suggestion for terminal package maintainers
Thomas Wolff: Checking escape sequences of function keys and keypad keys, there are many similarities (and common deficiencies) with Linux console and some weird differences: * Linux console (SUSE, don't know if it's really consistent) defines function keys F1...F12 and Shift-F1...Shift-F8 (very weird to stop here). The reason for the might be that the VT220 had 20 function keys. Shift-F1...Shift-F8 emulate F13...F20. * Cygwin console Shift-F1 and Shift-F2 are identical to F11 and F12, I don't think that's intended, I guess it should also be changed on the occasion of revising the console. * Cygwin console has shifted function keys up to Shift-F10, no F11/F12. Seems they took the approach that Shift adds 10 rather than 12 to the function key number. I'd suspect that's because XT and AT keyboards only had 10 function keys. Not quite the pseudo terminal. It's the readline function (of bash, cat, ...) so obviously ^? rubs out the ESC again as it should. It's readline for bash, but the terminal device for programs like cat or od, which don't use the readline library. By the way, I've always wondered why I cannot use cat for a quick test of most keyboard escape sequences in cygwin. This works quite nicely in Linux (except for the case above, apparently). On cygwin, entering cursor keys to cat just lets the cursor wander around, while on Linux it echoes the escapes Hmm, looks like 'cat' on Cygwin doesn't disable echoing in the terminal driver then. Assuming it's unmodified source, perhaps it gets configured differently for some reason. Andy
• The library or libraries will be delivered in compiled form, and will have been compiled using the GNU compiler for VxWorks-6.2. The library or libraries will be suitable for use within a VxWork
Ken Brown said: But it does seem that the release of 1.7 is a good time to ... You know, folks, at some point we need to stop saying 1.7 is a good time to make massive change X and just release it. We already have the following backwards incompatible [*] changes 1) dropping support for Win9x 2) no longer launch native programs from long or virtual CWDs (before, IIRC cygwin-1.5 would 'fake' the CWD as c:/ or something) 3) wide char support (and various existing changes related to LANG settings in console and other terminal sessions) 4) removal of registry usage / new mount table 5) old signal mask support removed (probably doesn't actually affect anyone) 6) [possible] switch to gcc4 as official compiler (with associated deliberate ABI breakage *without* DLL version number bumps -- see http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html). It's pretty clear this will happen *eventually*. Whether it happens before/on/soon-after the 1.7 rollout is still TBD. [*] for some definition of backwards incompatible. Mostly, I'm not listing strict improvements, but only things whose behavior has changed in a way that either explicitly breaks old programs or might be surprising to a naive user. I'm sure I've missed some items. Each time we say 1.7 is a good time to... and pull the trigger, it's another month of stabilization. During that month somebody ELSE has a bright idea about yet another thing 1.7 would be a good time to This is not good. -- Chuck
Re: Suggestion for terminal package maintainers
Sorry about that weird subject line. I have no idea what happened. On Wed, 03 Jun 2009 16:39 -0400, Charles Wilson wrote: Ken Brown said: But it does seem that the release of 1.7 is a good time to ... You know, folks, at some point we need to stop saying 1.7 is a good time to make massive change X and just release it. We already have the following backwards incompatible [*] changes 1) dropping support for Win9x 2) no longer launch native programs from long or virtual CWDs (before, IIRC cygwin-1.5 would 'fake' the CWD as c:/ or something) 3) wide char support (and various existing changes related to LANG settings in console and other terminal sessions) 4) removal of registry usage / new mount table 5) old signal mask support removed (probably doesn't actually affect anyone) 6) [possible] switch to gcc4 as official compiler (with associated deliberate ABI breakage *without* DLL version number bumps -- see http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html). It's pretty clear this will happen *eventually*. Whether it happens before/on/soon-after the 1.7 rollout is still TBD. [*] for some definition of backwards incompatible. Mostly, I'm not listing strict improvements, but only things whose behavior has changed in a way that either explicitly breaks old programs or might be surprising to a naive user. I'm sure I've missed some items. Each time we say 1.7 is a good time to... and pull the trigger, it's another month of stabilization. During that month somebody ELSE has a bright idea about yet another thing 1.7 would be a good time to This is not good. -- Chuck
src/winsup/cygwin ChangeLog fhandler_console.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-03 11:07:41 Modified files: winsup/cygwin : ChangeLog fhandler_console.cc Log message: * fhandler_console.cc (fhandler_console::read): Convert Alt-Backspace to \033\177 or to \377 dependent on the setting of dev_state-metabit. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4499r2=1.4500 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_console.cc.diff?cvsroot=srcr1=1.192r2=1.193
src/winsup/cygwin ChangeLog strfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-03 17:23:39 Modified files: winsup/cygwin : ChangeLog strfuncs.cc Log message: * strfuncs.cc (sys_cp_wcstombs): Implement reverse functionality of the change to sys_cp_mbstowcs from 2009-05-30. (sys_cp_mbstowcs): Slightly reformat. Fix comment to accommodate change to sys_cp_wcstombs. Don't write to *ptr if dst is NULL. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4500r2=1.4501 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strfuncs.cc.diff?cvsroot=srcr1=1.30r2=1.31
src/winsup/cygwin ChangeLog strfuncs.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-06-03 19:04:07 Modified files: winsup/cygwin : ChangeLog strfuncs.cc Log message: * strfuncs.cc (sys_cp_mbstowcs): Fix condition. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4501r2=1.4502 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strfuncs.cc.diff?cvsroot=srcr1=1.31r2=1.32
[PATCH] Pthread fixes arising.
Hi everyone,
The attached patch fixes the pthread bugs discovered and reported between
Thomas Stalder and myself. The winbase.h inline asms bug has already been the
subject of a long thread.
The latest fix is a simple racy optimisation in __cygwin_lock_{,un}lock;
they attempt to save themselves the bother of locking if multiple threads
aren't in operation, but when you have threads asynchronously being born and
dying, this can mean that the number of locks and unlocks becomes mismatched,
as the optimisation decision can be taken differently for both halves of a
matching lock/unlock pair of calls. Here's an example of it going wrong in
practice:
84 47795 [main] stalder3 3612 __cygwin_lock_lock: threadcount 2. locking
4981 47948 [main] stalder3 3612 __cygwin_lock_lock: threadcount 2. locking
* other thread dies here
-4876 43704 [main] stalder3 3612 __cygwin_lock_unlock: threadcount 1. not
unlocking
48 43752 [main] stalder3 3612 __cygwin_lock_unlock: threadcount 1. not
unlocking
main thinks it has unlocked the lock but it still holds it *
-4874 44571 [main] stalder3 3612 __cygwin_lock_lock: threadcount 2. locking
4982 49599 [main] stalder3 3612 __cygwin_lock_lock: threadcount 2. locking
4968 50294 [main] stalder3 3612 __cygwin_lock_unlock: threadcount 2.
unlocked
4969 50398 [main] stalder3 3612 __cygwin_lock_unlock: threadcount 2.
unlocked
*** main is now taking and releasing it recursively with a bias of one
105 50554 [unknown (0x7F4)] stalder3 3612 __cygwin_lock_lock: threadcount
2. locking
Now this thread waits potentially forever to take the lock. But while it is
doing this, it happens to be holding the user-level mutex. As soon as the
main thread next waits on this mutex, while still recursively holding the
__cygwin_lock_* mutex, we have a classic deadlock caused by priority
inversion. I don't figure the optimisation is worth the trouble - in theory
we could perhaps still try and hang onto it from program startup until the
first user thread gets created and then make sure it never gets re-enabled for
the rest of the runtime even if the number of threads drops back down again,
and the worst that would happen is excess unlock calls, but even that seems a
bit ugly. So I dropped it altogether.
winsup/cygwin/ChangeLog
* thread.cc (__cygwin_lock_lock): Delete racy optimisation.
(__cygwin_lock_unlock): Likewise.
* winbase.h (ilockexch): Fix asm constraints.
(ilockcmpexch): Likewise.
OK for head?
cheers,
DaveK
? winsup/cygwin/cygwin-cxx.h
? winsup/cygwin/mutex
Index: winsup/cygwin/thread.cc
===
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.215
diff -p -u -r1.215 thread.cc
--- winsup/cygwin/thread.cc 20 Jan 2009 12:40:31 - 1.215
+++ winsup/cygwin/thread.cc 3 Jun 2009 17:38:06 -
@@ -76,13 +76,8 @@ __cygwin_lock_fini (_LOCK_T *lock)
extern C void
__cygwin_lock_lock (_LOCK_T *lock)
{
- if (MT_INTERFACE-threadcount = 1)
-paranoid_printf (threadcount %d. not locking, MT_INTERFACE-threadcount);
- else
-{
- paranoid_printf (threadcount %d. locking, MT_INTERFACE-threadcount);
- pthread_mutex_lock ((pthread_mutex_t*) lock);
-}
+ paranoid_printf (threadcount %d. locking, MT_INTERFACE-threadcount);
+ pthread_mutex_lock ((pthread_mutex_t*) lock);
}
extern C int
@@ -95,13 +90,8 @@ __cygwin_lock_trylock (_LOCK_T *lock)
extern C void
__cygwin_lock_unlock (_LOCK_T *lock)
{
- if (MT_INTERFACE-threadcount = 1)
-paranoid_printf (threadcount %d. not unlocking, MT_INTERFACE-threadcount);
- else
-{
- pthread_mutex_unlock ((pthread_mutex_t*) lock);
- paranoid_printf (threadcount %d. unlocked, MT_INTERFACE-threadcount);
-}
+ pthread_mutex_unlock ((pthread_mutex_t*) lock);
+ paranoid_printf (threadcount %d. unlocked, MT_INTERFACE-threadcount);
}
static inline verifyable_object_state
Index: winsup/cygwin/winbase.h
===
RCS file: /cvs/src/src/winsup/cygwin/winbase.h,v
retrieving revision 1.14
diff -p -u -r1.14 winbase.h
--- winsup/cygwin/winbase.h 12 Jul 2008 18:09:17 - 1.14
+++ winsup/cygwin/winbase.h 3 Jun 2009 17:38:06 -
@@ -38,21 +38,21 @@ ilockdecr (volatile long *m)
extern __inline__ long
ilockexch (volatile long *t, long v)
{
- register int __res;
+ register long __res __asm__ (%eax) = *t;
__asm__ __volatile__ (\n\
-1: lock cmpxchgl %3,(%1)\n\
+1: lock cmpxchgl %2,%1\n\
jne 1b\n\
- : =a (__res), =q (t): 1 (t), q (v), 0 (*t): cc);
+ : +a (__res), =m (*t): q (v), m (*t) : memory, cc);
return __res;
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
- register int __res;
+ register long __res __asm (%eax) = c;
__asm__ __volatile__ (\n\
- lock cmpxchgl %3,(%1)\n\
- : =a (__res), =q
Re: [PATCH] Pthread fixes arising.
Dave Korn wrote: *** main is now taking and releasing it recursively with a bias of one Two, not one. cheers, DaveK
Re: [PATCH] Pthread fixes arising.
On Wed, Jun 03, 2009 at 07:16:04PM +0100, Dave Korn wrote: winsup/cygwin/ChangeLog * thread.cc (__cygwin_lock_lock): Delete racy optimisation. (__cygwin_lock_unlock): Likewise. * winbase.h (ilockexch): Fix asm constraints. (ilockcmpexch): Likewise. OK for head? Which version of the asm constraints are these? If this is the I'm pretty sure I know what I'm doing version then no. If these are the versions from some tried-and-true OS/library then yes. Actually maybe this should be two checkins since the __cygwin_lock_lock stuff is uncontroversial. cgf
[PATCH] Separate pthread fixes #1
The attached patch separates out the uncontroversial change to the
__cygwin_lock* functions.
winsup/cygwin/ChangeLog
* thread.cc (__cygwin_lock_lock): Delete racy optimisation.
(__cygwin_lock_unlock): Likewise.
OK?
cheers,
DaveK
Index: winsup/cygwin/thread.cc
===
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.215
diff -p -u -r1.215 thread.cc
--- winsup/cygwin/thread.cc 20 Jan 2009 12:40:31 - 1.215
+++ winsup/cygwin/thread.cc 3 Jun 2009 22:53:40 -
@@ -76,13 +76,8 @@ __cygwin_lock_fini (_LOCK_T *lock)
extern C void
__cygwin_lock_lock (_LOCK_T *lock)
{
- if (MT_INTERFACE-threadcount = 1)
-paranoid_printf (threadcount %d. not locking, MT_INTERFACE-threadcount);
- else
-{
- paranoid_printf (threadcount %d. locking, MT_INTERFACE-threadcount);
- pthread_mutex_lock ((pthread_mutex_t*) lock);
-}
+ paranoid_printf (threadcount %d. locking, MT_INTERFACE-threadcount);
+ pthread_mutex_lock ((pthread_mutex_t*) lock);
}
extern C int
@@ -95,13 +90,8 @@ __cygwin_lock_trylock (_LOCK_T *lock)
extern C void
__cygwin_lock_unlock (_LOCK_T *lock)
{
- if (MT_INTERFACE-threadcount = 1)
-paranoid_printf (threadcount %d. not unlocking, MT_INTERFACE-threadcount);
- else
-{
- pthread_mutex_unlock ((pthread_mutex_t*) lock);
- paranoid_printf (threadcount %d. unlocked, MT_INTERFACE-threadcount);
-}
+ pthread_mutex_unlock ((pthread_mutex_t*) lock);
+ paranoid_printf (threadcount %d. unlocked, MT_INTERFACE-threadcount);
}
static inline verifyable_object_state
[PATCH?] Separate pthread patches, #2 take 2.
The attached patch implements ilockexch and ilockcmpexch, using the inline
asm definition from __arch_compare_and_exchange_val_32_acq in
glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline rather
than in its original preprocessor macro form.
It generates incorrect code. The sequence discussed before,
126 do
127 node-next = head;
128 while (InterlockedCompareExchangePointer (head, node, node-next) !=
node-next);
is now compiled down to this loop:
L186:
.loc 3 127 0
movl__ZN13pthread_mutex7mutexesE+8, %edx # mutexes.head, D.28599
.loc 2 58 0
movl%edx, %eax # D.28599, tmp68
/APP
# 58 /gnu/winsup/src/winsup/cygwin/winbase.h 1
lock cmpxchgl %ebx, __ZN13pthread_mutex7mutexesE+8 # this,
# 0 2
/NO_APP
movl%eax, -12(%ebp) # tmp68, ret
.loc 2 59 0
movl-12(%ebp), %eax # ret, D.28596
.loc 3 126 0
cmpl%eax, %edx # D.28596, D.28599
jne L186 #,
movl%edx, 36(%ebx) # D.28599, variable.next
... which is in fact the equivalent of
126 do
127 ;
128 while (InterlockedCompareExchangePointer (head, node, node-next) !=
node-next);
(126) node-next = head;
As it caches the values of head in %edx during the spin loop, and only
stores it to node-next after having overwritten *head with node, there is a
short window after the new node is linked to the front of the chain during
which its chain pointer is incorrect.
Not OK for head?
cheers,
DaveK
Index: winsup/cygwin/winbase.h
===
RCS file: /cvs/src/src/winsup/cygwin/winbase.h,v
retrieving revision 1.14
diff -p -u -r1.14 winbase.h
--- winsup/cygwin/winbase.h 12 Jul 2008 18:09:17 - 1.14
+++ winsup/cygwin/winbase.h 3 Jun 2009 22:54:38 -
@@ -34,27 +34,31 @@ ilockdecr (volatile long *m)
: =r (__res), =m (*m): m (*m): cc);
return __res;
}
-
-extern __inline__ long
-ilockexch (volatile long *t, long v)
-{
- register int __res;
- __asm__ __volatile__ (\n\
-1: lock cmpxchgl %3,(%1)\n\
- jne 1b\n\
- : =a (__res), =q (t): 1 (t), q (v), 0 (*t): cc);
- return __res;
-}
-
-extern __inline__ long
-ilockcmpexch (volatile long *t, long v, long c)
-{
- register int __res;
- __asm__ __volatile__ (\n\
- lock cmpxchgl %3,(%1)\n\
- : =a (__res), =q (t) : 1 (t), q (v), 0 (c): cc);
- return __res;
-}
+
+extern __inline__ long
+ilockexch (volatile long *t, long v)
+{
+ return ({
+ __typeof (*t) ret;
+ __asm __volatile (1: lock cmpxchgl %2, %1\n
+ jne 1b\n
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (*t));
+ ret;
+ });
+}
+
+extern __inline__ long
+ilockcmpexch (volatile long *t, long v, long c)
+{
+ return ({
+ __typeof (*t) ret;
+ __asm __volatile (lock cmpxchgl %2, %1
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (c));
+ ret;
+ });
+}
#undef InterlockedIncrement
#define InterlockedIncrement ilockincr
Re: [PATCH?] Separate pthread patches, #2 take 3
Dave Korn wrote:
The attached patch implements ilockexch and ilockcmpexch, using the inline
asm definition from __arch_compare_and_exchange_val_32_acq in
glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline rather
than in its original preprocessor macro form.
The attached patch does likewise, but adds a memory clobber. It generates
correct code:
L186:
.loc 3 127 0
movl__ZN13pthread_mutex7mutexesE+8, %eax # mutexes.head, D.28599
movl%eax, 36(%ebx) # D.28599, variable.next
.loc 2 60 0
/APP
# 60 /gnu/winsup/src/winsup/cygwin/winbase.h 1
lock cmpxchgl %ebx, __ZN13pthread_mutex7mutexesE+8 # this,
# 0 2
/NO_APP
movl%eax, -12(%ebp) # tmp68, ret
.loc 2 61 0
movl-12(%ebp), %eax # ret, D.28596
.loc 3 126 0
cmpl%eax, 36(%ebx) # D.28596, variable.next
jne L186 #,
although as you see it has some needless register motion as it stores %eax to
the stack slot for ret and reloads it. Still, this is now almost as good as
the code generated by my original patch.
winsup/cygwin/ChangeLog
* winbase.h (ilockexch): Fix asm constraints.
(ilockcmpexch): Likewise.
Ok-ish?
cheers,
DaveK
Index: winsup/cygwin/winbase.h
===
RCS file: /cvs/src/src/winsup/cygwin/winbase.h,v
retrieving revision 1.14
diff -p -u -r1.14 winbase.h
--- winsup/cygwin/winbase.h 12 Jul 2008 18:09:17 - 1.14
+++ winsup/cygwin/winbase.h 3 Jun 2009 23:28:02 -
@@ -38,22 +38,28 @@ ilockdecr (volatile long *m)
extern __inline__ long
ilockexch (volatile long *t, long v)
{
- register int __res;
- __asm__ __volatile__ (\n\
-1: lock cmpxchgl %3,(%1)\n\
- jne 1b\n\
- : =a (__res), =q (t): 1 (t), q (v), 0 (*t): cc);
- return __res;
+ return ({
+ __typeof (*t) ret;
+ __asm __volatile (1: lock cmpxchgl %2, %1\n
+ jne 1b\n
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (*t)
+ : memory);
+ ret;
+ });
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
- register int __res;
- __asm__ __volatile__ (\n\
- lock cmpxchgl %3,(%1)\n\
- : =a (__res), =q (t) : 1 (t), q (v), 0 (c): cc);
- return __res;
+ return ({
+ __typeof (*t) ret;
+ __asm __volatile (lock cmpxchgl %2, %1
+ : =a (ret), =m (*t)
+ : r (v), m (*t), 0 (c)
+ : memory);
+ ret;
+ });
}
#undef InterlockedIncrement
Re: [PATCH?] Separate pthread patches, #2 take 1 redux
Dave Korn wrote:
Dave Korn wrote:
The attached patch implements ilockexch and ilockcmpexch, using the inline
asm definition from __arch_compare_and_exchange_val_32_acq in
glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline
rather
than in its original preprocessor macro form.
And this one, just to have the full set in the same place, is the version
that I originally suggested. It generates correct and efficient code:
L215:
.loc 3 127 0
movl__ZN13pthread_mutex7mutexesE+8, %eax # mutexes.head, D.28638
movl%eax, 36(%ebx) # D.28638, variable.next
.loc 2 53 0
/APP
# 53 /gnu/winsup/src/winsup/cygwin/winbase.h 1
lock cmpxchgl %ebx,__ZN13pthread_mutex7mutexesE+8# this,
# 0 2
/NO_APP
.loc 3 126 0
cmpl%eax, 36(%ebx) # D.28635, variable.next
jne L215 #,
but is more risky. No ChangeLog because it's not going to be approved, I'm
posting it just for completeness and future reference.
cheers,
DaveK
Index: winsup/cygwin/winbase.h
===
RCS file: /cvs/src/src/winsup/cygwin/winbase.h,v
retrieving revision 1.14
diff -p -u -r1.14 winbase.h
--- winsup/cygwin/winbase.h 12 Jul 2008 18:09:17 - 1.14
+++ winsup/cygwin/winbase.h 3 Jun 2009 17:38:06 -
@@ -38,21 +38,21 @@ ilockdecr (volatile long *m)
extern __inline__ long
ilockexch (volatile long *t, long v)
{
- register int __res;
+ register long __res __asm__ (%eax) = *t;
__asm__ __volatile__ (\n\
-1: lock cmpxchgl %3,(%1)\n\
+1: lock cmpxchgl %2,%1\n\
jne 1b\n\
- : =a (__res), =q (t): 1 (t), q (v), 0 (*t): cc);
+ : +a (__res), =m (*t): q (v), m (*t) : memory, cc);
return __res;
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
- register int __res;
+ register long __res __asm (%eax) = c;
__asm__ __volatile__ (\n\
- lock cmpxchgl %3,(%1)\n\
- : =a (__res), =q (t) : 1 (t), q (v), 0 (c): cc);
+ lock cmpxchgl %2,%1\n\
+ : +a (__res), =m (*t) : q (v), m (*t) : memory, cc);
return __res;
}
Re: [PATCH?] Separate pthread patches, #2 take 2.
Dave Korn wrote: The attached patch implements ilockexch and ilockcmpexch, using the inline asm definition from __arch_compare_and_exchange_val_32_acq in glibc-2.10.1/sysdeps/i386/i486/bits/atomic.h, trivially expanded inline rather than in its original preprocessor macro form. It generates incorrect code. This much looks like it's probably a compiler bug. This version, compiled with current GCC HEAD, generates the same results as in the take 3 version, without needing the explicit memory clobber added: L469: .loc 2 127 0 movl__ZN13pthread_mutex7mutexesE+8, %eax # mutexes.head, D.30413 movl%eax, 36(%ebx) # D.30413, variable.next .loc 5 58 0 /APP # 58 /gnu/winsup/src/winsup/cygwin/winbase.h 1 lock cmpxchgl %ebx, __ZN13pthread_mutex7mutexesE+8 # this, # 0 2 /NO_APP movl%eax, -12(%ebp) # tmp76, ret .loc 5 59 0 movl-12(%ebp), %eax # ret, D.30414 .loc 2 126 0 cmpl%eax, 36(%ebx) # D.30414, variable.next jne L469 #, ... right down to the unoptimised register motion. This is what we would have hoped to see: the memory clobber ought to be superfluous, and the write-output operand in *t should have told GCC not to move the store to node-next after the loop. I checked 4.3.3; it behaves the same as 4.3.2, i.e. it incorrectly lowers the store without a memory clobber present. cheers, DaveK
Re: [PATCH?] Separate pthread patches, #2 take 3
Christopher Faylor wrote:
I thought that, given your last message to cygwin-developers, you were
going to go off and figure out the best of four implementations. Is this
the result of that investigation?
Once I discarded the ones that weren't quite right because they included a
setz/sete instruction (bsd and boehm), I was left with the ones in the
attached testcase. The only version I hadn't tested yet is the linux-derived
one:
struct __xchg_dummy { unsigned long a[100]; };
#define __xg(x) ((struct __xchg_dummy *)(x))
#define LOCK_PREFIX lock
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long newv)
{
unsigned long prev;
__asm__ __volatile__(LOCK_PREFIX cmpxchgl %1,%2
: =a(prev)
: q(newv), m(*__xg(ptr)), 0(old)
: memory);
return prev;
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
return __cmpxchg (t, c, v);
}
This actually produces the same assembly as my version:
L14:
movl__ZN13pthread_mutex7mutexesE, %eax # mutexes.head, D.2029
movl%eax, 36(%ebx) # D.2029, variable.next
/APP
# 75 mxfull.cpp 1
lock cmpxchgl %ebx,__ZN13pthread_mutex7mutexesE # this,
# 0 2
/NO_APP
cmpl%eax, 36(%ebx) # prev, variable.next
jne L14 #,
but it's a horrible bit of code. Declaring the memory location as input only,
then clobbering all of memory and potentially confusing the optimisers with
type aliasing casts? It makes me very uneasy.
cheers,
DaveK
// g++ -c mxfull.cpp -o mxfull.o --save-temps -O2 -fverbose-asm
typedef long LONG;
typedef void *HANDLE;
typedef void *PVOID;
typedef char *LPCSTR;
typedef class pthread_mutex *pthread_mutex_t;
typedef class pthread_mutexattr *pthread_mutexattr_t;
typedef class pthread *pthread_t;
struct SECURITY_ATTRIBUTES;
typedef struct SECURITY_ATTRIBUTES *LPSECURITY_ATTRIBUTES;
extern struct SECURITY_ATTRIBUTES sec_none_nih;
HANDLE __attribute__((__stdcall__))
CreateSemaphoreA(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCSTR);
class verifyable_object
{
public:
long magic;
verifyable_object (long);
virtual ~verifyable_object ();
};
#if 0
// My version
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
register long __res __asm (%eax) = c;
__asm__ __volatile__ (\n\
lock cmpxchgl %2,%1\n\
: +a (__res), =m (*t) : q (v), m (*t) : memory, cc);
return __res;
}
#elif 0
// Original version
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
register int __res;
__asm__ __volatile__ (\n\
lock cmpxchgl %3,(%1)\n\
: =a (__res), =q (t) : 1 (t), q (v), 0 (c): cc);
return __res;
}
#elif 0
// GlibC/uClibC version
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
return ({
__typeof (*t) ret;
__asm __volatile (lock cmpxchgl %2, %1
: =a (ret), =m (*t)
: r (v), m (*t), 0 (c));
ret;
});
}
#elif 01
// Linux-2.6.8-1 version
struct __xchg_dummy { unsigned long a[100]; };
#define __xg(x) ((struct __xchg_dummy *)(x))
#define LOCK_PREFIX lock
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long newv)
{
unsigned long prev;
__asm__ __volatile__(LOCK_PREFIX cmpxchgl %1,%2
: =a(prev)
: q(newv), m(*__xg(ptr)), 0(old)
: memory);
return prev;
}
extern __inline__ long
ilockcmpexch (volatile long *t, long v, long c)
{
return __cmpxchg (t, c, v);
}
#endif
class pthread_mutexattr: public verifyable_object
{
public:
int pshared;
int mutextype;
pthread_mutexattr ();
~pthread_mutexattr ();
};
template class list_node inline void
List_insert (list_node *head, list_node *node)
{
if (!node)
return;
do
node-next = head;
while ((PVOID)ilockcmpexch((LONG volatile
*)(head),(LONG)(node),(LONG)(node-next)) != node-next);
}
template class list_node class List
{
public:
List() : head(__null)
{
}
~List()
{
}
void insert (list_node *node)
{
List_insert (head, node);
}
list_node *head;
};
class pthread_mutex: public verifyable_object
{
public:
unsigned long lock_counter;
HANDLE win32_obj_id;
unsigned int recursion_counter;
LONG condwaits;
pthread_t owner;
int type;
int pshared;
pthread_mutex (pthread_mutexattr * = __null);
~pthread_mutex ();
class pthread_mutex * next;
private:
static Listpthread_mutex mutexes;
};
Listpthread_mutex pthread_mutex::mutexes;
pthread_mutex::pthread_mutex (pthread_mutexattr *attr) :
verifyable_object (0xdf0df045
Re: [PATCH?] Separate pthread patches, #2 take 3
On Thu, Jun 04, 2009 at 04:03:03AM +0100, Dave Korn wrote: but it's a horrible bit of code. Declaring the memory location as input only, then clobbering all of memory and potentially confusing the optimisers with type aliasing casts? It makes me very uneasy. Ok. I'm convinced. Please check in whatever you think is best. cgf
Re: [PATCH?] Separate pthread patches, #2 take 3
Christopher Faylor wrote: On Thu, Jun 04, 2009 at 04:03:03AM +0100, Dave Korn wrote: but it's a horrible bit of code. Declaring the memory location as input only, then clobbering all of memory and potentially confusing the optimisers with type aliasing casts? It makes me very uneasy. Ok. I'm convinced. Please check in whatever you think is best. cgf I will wait and see what advice the gcc list has to offer on the topic first. It may yet cast a new light on things. (Or it may just confirm my suspicions that even in trusted and well-tested library code, there has been a fair deal of ad-hoc-ery and copypastaing of inline asms that people didn't really grok.) I'll also see if I can dig up any recent PRs or fixes that might have a bearing on why we get better code from HEAD than 4.3. cheers, DaveK
Re: [1.7] pthread_mutex_lock/pthread_mutex_unlock strange blocking problem
On Jun 3 01:12, Dave Korn wrote: Corinna Vinschen wrote: On Jun 2 16:11, Thomas Stalder wrote: Hello, Sometimes pthread_mutex_lock ou pthread_mutex_unlock block. Isn't that basically the same problem Dave sent the patch to fix the hangs in pthread_create? Nope, the problem reproduces for me even with the current fix; I'll see if I can figure out what's going wrong. Cool, thanks. 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: UAC .manifest files
On Jun 2 23:21, Yaakov S wrote: I think the best solution is to let cygport detect susceptible apps and generate .manifest files automatically. 1. AFAICS, this affects EXEs with names containing install, patch, setup, or update. Are there any more patterns? I never saw more than exactly this list. 2. According to MSDN[1], the name attribute of the assemblyIdentity subelement should be uniquely named in a Organization.Division.Name format. Our existing manifests don't do that; should we? Does it matter? I don't know if it matters, but it certainly doesn't hurt either. As a suggestion, when automating this, the name could be constructed like this: Organization=Cygwin Division=packagename Name=executable 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: Cygwin SSH Multiple Users
Hello, We have configured Cygwin on Windows XP. SOmehow we managed to configure the SSH onto cygwin for a user called mac. We could login to windows XP with the local user name mac and then start the cygwin. And then /usr/sbin/sshd. Its the only way currently how we get to start the sshd daemon. And we could connect from remote system to this XP system using ssh -l mac winxp. But now the problem is we can not make other users login to this winxp host. Here are few of the details help you understand the environment, $ ls -l /etc/ssh* -rwxr-x--- 1 mac Kein 1482 Mar 23 13:47 /etc/ssh_config -rw--- 1 mac Kein 668 Mar 23 13:47 /etc/ssh_host_dsa_key -rw-r--r-- 1 mac Kein 603 Mar 23 13:47 /etc/ssh_host_dsa_key.pub -rw--- 1 mac Kein 976 Mar 23 13:47 /etc/ssh_host_key -rw-r--r-- 1 mac Kein 640 Mar 23 13:47 /etc/ssh_host_key.pub -rw--- 1 mac Kein 1671 Mar 23 13:47 /etc/ssh_host_rsa_key -rw-r--r-- 1 mac Kein 395 Mar 23 13:47 /etc/ssh_host_rsa_key.pub -rw-r--r-- 1 mac Kein 3258 Mar 23 13:48 /etc/sshd_config $ ls -ld /var/empty/ drwxr-xr-x+ 2 mac Kein 0 Mar 23 13:47 /var/empty/ Please let us know if you need anymore information. Kindly suggest or point us in right direction. Thanks and Regards, Sac -- 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: UAC .manifest files
On Jun 3 10:11, Corinna Vinschen wrote: On Jun 2 23:21, Yaakov S wrote: I think the best solution is to let cygport detect susceptible apps and generate .manifest files automatically. 1. AFAICS, this affects EXEs with names containing install, patch, setup, or update. Are there any more patterns? I never saw more than exactly this list. With a small change: s/install/instal/ 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Larry Hall (Cygwin) wrote:
Try another mirror. It's listed on one or both of the mirrors below:
ftp://sourceware.mirrors.tds.net
ftp://mirrors.kernel.org
OK, Thanks! Got that from the latter.
However now that I compile the perl CPAN module: Math::GMP 2.05,
I get a lot of compilation errors:
gcc -c -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe
-I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\2.05\
-DXS_VERSION=\2.05\ -I/usr/lib/perl5/5.10/i686-cygwin/CORE GMP.c
GMP.c: In function `XS_Math__GMP_destroy':
GMP.c:161: warning: cast to pointer from integer of different size
...
The same for nearly all the functions, but here is the one mentioned above:
Math-GMP-2.05 perl -nle 'print $.: $_ if 145..171' GMP.c
145: XS(XS_Math__GMP_destroy); /* prototype to pass -Wmissing-prototypes */
146: XS(XS_Math__GMP_destroy)
147: {
148: #ifdef dVAR
149: dVAR; dXSARGS;
150: #else
151: dXSARGS;
152: #endif
153: if (items != 1)
154:Perl_croak(aTHX_ Usage: %s(%s), Math::GMP::destroy, n);
155: PERL_UNUSED_VAR(cv); /* -W */
156: {
157:mpz_t * n;
158:
159: if (sv_derived_from(ST(0), Math::GMP)) {
160: IV tmp = SvIV((SV*)SvRV(ST(0)));
161: n = (mpz_t *) tmp;
162: }
163: else
164: croak(n is not of type Math::GMP);
165: #line 90 GMP.xs
166: mpz_clear(*n);
167: free(n);
168: #line 169 GMP.c
169: }
170: XSRETURN_EMPTY;
171: }
mpz_t is typdedef'ed in /usr/include/gmp.h
(I hope the __GNU_MP__ concerns us...):
typedef struct
{
int _mp_alloc;/* Number of *limbs* allocated and pointed
to by the _mp_d field. */
int _mp_size; /* abs(_mp_size) is the number of limbs the
last field points to. If _mp_size is
negative this is a negative number. */
mp_limb_t *_mp_d; /* Pointer to the limbs. */
} __mpz_struct;
#endif /* __GNU_MP__ */
typedef __mpz_struct MP_INT;/* gmp 1 source compatibility */
typedef __mpz_struct mpz_t[1];
Where does IV come from is what I'll try to find next.
Marc
--
View this message in context:
http://www.nabble.com/Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23830861p23849366.html
Sent from the Cygwin list 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod wrote: Where does IV come from is what I'll try to find next. This seems to be from the perlapi: sv_iv A private implementation of the SvIVx macro for compilers which can't cope with complex macro expressions. Always use the macro instead. IV sv_iv(SV* sv) In /usr/lib/perl5/5.10/i686-cygwin/CORE/perl.h: ... /* The IV type is supposed to be long enough to hold any integral value or a pointer. --Andy DoughertyAugust 1996 */ typedef IVTYPE IV; Now, you'd ask... what about IVTYPE? /usr/lib/perl5/5.10/i686-cygwin/CORE/config.h has: /* IVTYPE: * This symbol defines the C type used for Perl's IV. */ ... #define IVTYPE long long /**/ /usr/lib/perl5/5.10/i686-cygwin/CORE/uconfig.h this: #define IVTYPE long/**/ and /usr/lib/perl5/5.10/i686-cygwin/Devel/PPPort.pm various definitions depending on context: #ifdef INTSIZE #ifndef IVSIZE # define IVSIZE INTSIZE #endif #endif # else #if defined(convex) || defined(uts) #ifndef IVTYPE # define IVTYPE long long #endif ... # ifdef LONGLONGSIZE #ifndef IVSIZE # define IVSIZE LONGLONGSIZE #endif # endif #else #ifndef IVTYPE # define IVTYPE long #endif So, it very much depends which definition is hit first... Marc -- View this message in context: http://www.nabble.com/Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23830861p23849850.html Sent from the Cygwin list 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: Re: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod marc.gi...@gmail.com wrote: I get a lot of compilation errors: gcc -c -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\2.05\ -DXS_VERSION=\2.05\ -I/usr/lib/perl5/5.10/i686-cygwin/CORE GMP.c GMP.c: In function `XS_Math__GMP_destroy': GMP.c:161: warning: cast to pointer from integer of different size ... No error there - just a warning, but that's not going to stop the compilation and should not be a problem. The warning can usually be silenced by using INT2PTR(). 160: IV tmp = SvIV((SV*)SvRV(ST(0))); 161: n = (mpz_t *) tmp; Try: n = INT2PTR(mpz_t*, tmp); I'm not sure about that being the fix - but it won't take long to test. Cheers, Rob Cheers, Rob -- 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 SSH Multiple Users
On 3-Jun-09, at 4:13 AM, Holikar, Sachin (ext) wrote: Hello, We have configured Cygwin on Windows XP. SOmehow we managed to configure the SSH onto cygwin for a user called mac. We could login to windows XP with the local user name mac and then start the cygwin. And then /usr/sbin/sshd. Its the only way currently how we get to start the sshd daemon. And we could connect from remote system to this XP system using ssh -l mac winxp. But now the problem is we can not make other users login to this winxp host. Here are few of the details help you understand the environment, Consider running the ssh-host-config script. -g -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Sisyphus wrote: No error there - just a warning, but that's not going to stop the compilation and should not be a problem. Correct, but after I install the result, trying to use it dumps core, which is why I suspected this (no other errors). e.g. 'perl Makefile.PL' for Net-SSH-Perl-1.34... I join a perl.exe.stackdump... http://www.nabble.com/file/p23850818/perl.exe.stackdump perl.exe.stackdump Marc -- View this message in context: http://www.nabble.com/Re%3A-Re%3A-Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23850368p23850818.html Sent from the Cygwin list 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod marc.gi...@gmail.com wrote: No error there - just a warning, but that's not going to stop the compilation and should not be a problem. Correct, but after I install the result, trying to use it dumps core, which is why I suspected this (no other errors). Any errors during the 'make test' phase of the Math-GMP-2.05 build ? I've seen quite a few reservations expressed re Net::SSH::Perl. Net::SSH2 seems to be a popular alternative (assuming you don't need the SSH1 protocol). I've found Net::SSH2 to be quite good (though I've only used it on 'native' win32) - haven't tried Net::SSH::Perl. Cheers, Rob -- 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/
Can I install cygwin from my own setup.ini?
Hi All, I only want to install the following modules: -- bash base-files sed gawk -- But it's an uneasy work to deselect all the unwanted modules from the default status on the cygwin setup dialog box. (And the selection work must be done again every time I invoke setup, if setup failed or I want to add/remove modules). I used an extern tool to calculate all the required modules from the basic module set by parsing the download setup.ini file and generate another ini file like: # This file is automatically generated. If you edit it, your # edits will be discarded next time the file is generated. # See http://cygwin.com/setup.html for details. # setup-timestamp: 1243714223 setup-version: 2.573.2.3 @ ELFIO @ base-files sdesc: A set of important system configuration and setup files ldesc: A set of important system configuration and setup files category: Base requires: bash coreutils findutils sed version: 3.7-1 install: release/base-files/base-files-3.7-1.tar.bz2 35398 4000a7079f671732128e1f1be4e4147c [prev] version: 3.6-1 install: release/base-files/base-files-3.6-1.tar.bz2 36312 0f226a7b43775b1b99a455d89457d0b1 @ bash sdesc: The GNU Bourne Again SHell ldesc: Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. category: Base Shells requires: cygwin libintl8 libreadline6 _update-info-dir version: 3.2.48-21 install: release/bash/bash-3.2.48-21.tar.bz2 581339 913315ce9509cb20921d8f742db3e52c source: release/bash/bash-3.2.48-21-src.tar.bz2 2608867 94d015723ca27524e85f9d882c3d1f1f [prev] version: 3.1-6 install: release/bash/bash-3.1-6.tar.bz2 519021 1771a41aaf381b8ae7641720b9d1564f source: release/bash/bash-3.1-6-src.tar.bz2 2576367 305a13b3df67ccf009ab9d98e6d9ca1a @ coreutils sdesc: GNU core utilities (includes fileutils, sh-utils and textutils) ldesc: Common core utilities include: [ arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid hostname id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stty su sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink users vdir wc who whoami yes category: Base requires: bash crypt cygwin libiconv2 libintl8 tzcode _update-info-dir version: 6.10-2 install: release/coreutils/coreutils-6.10-2.tar.bz2 3162007 e2bc2753be6be301f51676dbd48ac46d source: release/coreutils/coreutils-6.10-2-src.tar.bz2 9101600 63f964d84a067285c5ec335d131d3a97 [prev] version: 6.10-1 install: release/coreutils/coreutils-6.10-1.tar.bz2 3162071 a23c486f0fb525e7febb15dce98ace13 source: release/coreutils/coreutils-6.10-1-src.tar.bz2 9095096 d8e748b0a74cb3ab604d83b8ef22fe34 @ crypt sdesc: Encryption/Decryption utility and library category: Libs requires: cygwin version: 1.1-1 install: release/crypt/crypt-1.1-1.tar.bz2 13181 7d7f1557a813840a537002ed593de194 source: release/crypt/crypt-1.1-1-src.tar.bz2 4465 4c0fb83c8929fffd8b1bbfd1e5b2af6d [prev] version: 1.0-2 install: release/crypt/crypt-1.0-2.tar.bz2 7755 c59920e8b9575e586f0401afc00ae6ff source: release/crypt/crypt-1.0-2-src.tar.bz2 3484 0b96e0211d5833416095996b668eb68b @ cygwin sdesc: The UNIX emulation engine category: Base version: 1.5.25-15 install: release/cygwin/cygwin-1.5.25-15.tar.bz2 1427096 b72f64b6d7e68b57aa849371706d6062 source: release/cygwin/cygwin-1.5.25-15-src.tar.bz2 11486150 e8b89ac647f1e0888a943f7db9573798 [prev] version: 1.5.25-14 install: release/cygwin/cygwin-1.5.25-14.tar.bz2 1392732 712f846abff7be978f14a946dedbe42a source: release/cygwin/cygwin-1.5.25-14-src.tar.bz2 9595245 53c8c2fa345f126a59517df44c80532f @ findutils sdesc: Utilities for finding files--find, xargs, locate, updatedb ldesc: The findutils package contains programs which will help you locate files on your system. The find utility searches through a hierarchy of directories looking for files which match a certain set of criteria (such as a filename pattern). The xargs utility builds and executes command lines from standard input arguments (usually lists of file names generated by the find command). The locate utility scans a database of filenames and displays matches. The updatedb utility builds the database for locate. category: Base requires: bash coreutils cygwin libintl8 _update-info-dir
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Corinna Vinschen wrote: On May 29 17:21, Edward Lam wrote: I think the problem I'm running into is: - I give cygwin 1.7's bash a string that is in my system default code page. - cygwin 1.7 thinks the string is actually UTF-8 and tries to convert it as UTF-8 into UTF-16, resulting in a truncated command line that is passed to child process. The question is, what do you expect? I know, you expect that it just works, but that's not as easy as you might assume, unfortunately. Yes, Alexey and I had a lengthy argument on this thread already. Disagreements on the default LANG behaviour notwithstanding, I think that it still should NOT truncate, substituting the invalid character with something else instead. Here's a quote from Alexey previously on this thread: In my opinion: truncation is a bug (should use replacement character, or fail exec altogether), expecting utf-8 is not Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Yoy get the idea. The character 0xa9 has no meaning in itself. It only has a meaning when you consider the character set or codepage in which you use this character. ... How is anybody supposed to know that the file which consists of the single byte 0xa9 has *any* meaning at all? Why should it be the copyright sign, of all things? What I was attempting to do was to have NO conversion. In the real case that I into this, the bug.exe was the one to properly interpret what the byte 0xA9 meant from the command line. Yes, I know there are several workarounds. If we default to the ANSI codepage, you will have the same problem, just upside down. In both cases you will have even more problems if you start using characters not available in your default codepage. This is where I disagreed with Alexey. What we're really arguing here is whether which default will run into the least problems for the most common usage. This is subjective of course. -Edward -- 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: Trouble with ssh-agent (maybe opening socket?)
I want to re-anime this thread because until now i did not figure out what the problem is, and using ssh from an admin station without ssh-agent is annoying. The problem appears only when ssh-agent is _not_ started with the -d ==debug option. So this means that only when ssh-agent forks after starting up it will start to eat full cpu after being connected through ssh-add. == here an example _with_ forking: == fi...@schlepptop ~ $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-332EpkBmHu/agent.5492; export SSH_AUTH_SOCK; SSH_AGENT_PID=4428; export SSH_AGENT_PID; echo Agent pid 4428; top tells me that ssh-agent is running but idling around... on other shell: fi...@schlepptop ~ $ export SSH_AUTH_SOCK=/tmp/ssh-332EpkBmHu/agent.5492; fi...@schlepptop ~ $ SSH_AGENT_PID=4428; export SSH_AGENT_PID; fi...@schlepptop ~ $ ssh-add --- cursor blinking here... waiting top tells me that ssh-agent is running on 100% cpu load, i have to kill ssh-agent.exe. == example _without_ forking: == fi...@schlepptop ~ $ ssh-agent -d SSH_AUTH_SOCK=/tmp/ssh-AJrrAAHVZk/agent.932; export SSH_AUTH_SOCK; echo Agent pid 932; -- cursor blinking here, ssh-agent did not fork other console: fi...@schlepptop ~ $ ssh-add Enter passphrase for /cygdrive/c/Dokume~1/C11188/.ssh/id_rsa: Identity added: /cygdrive/c/Dokume~1/C11188/.ssh/id_rsa (/cygdrive/c/Dokume~1/C11188/.ssh/id_rsa) Identity added: /cygdrive/c/Dokume~1/C11188/.ssh/id_dsa (/cygdrive/c/Dokume~1/C11188/.ssh/id_dsa) --- everything works fine. So this might be a problem with forking. I did not get strace to connect to the forked process, the command strace -p pid_of_ssh-agent just does not give me any output. Is there any way to gather more information so that you can help me? By the way, since i have this problem with ssh-agent i have also a problem with FreeNX Windows Client which - if i am not totally confused - also ships some cygwin dlls whith it. NX Client does authenticate to remote host, then stays in Negotiating link parameters and then dies. Maybe these two problems has something to do one with the other? I would be very happy if you could give me some good ideas. Christian -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Sisyphus wrote: I've found Net::SSH2 to be quite good (though I've only used it on 'native' win32) - haven't tried Net::SSH::Perl. Thanks. tried it. However, 'perl Makefile.PL' doesn't seem to find the bits I installed from libssh2-devel. I had to set: my $lib = '/usr/lib'; my $inc = '/usr/include'; Even with those, the compilation fails: gcc -c -I/usr/include -I. -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\0.20\ -DXS_VERSION=\0.20\ -I/usr/lib/perl5/5.10/i686-cygwin/CORE SSH2.c In file included from SSH2.xs:11: ppport.h:3042:1: warning: PERL_UNUSED_DECL redefined In file included from SSH2.xs:8: /usr/lib/perl5/5.10/i686-cygwin/CORE/perl.h:317:1: warning: this is the location of the previous definition SSH2.c: In function `XS_Net__SSH2_blocking': SSH2.c:708: warning: cast to pointer from integer of different size SSH2.c: In function `XS_Net__SSH2_DESTROY': SSH2.c:736: warning: cast to pointer from integer of different size SSH2.xs: In function `XS_Net__SSH2_version': SSH2.xs:581: error: `LIBSSH2_VERSION_NUM' undeclared (first use in this function) SSH2.xs:581: error: (Each undeclared identifier is reported only once SSH2.xs:581: error: for each function it appears in.) ... make: *** [SSH2.o] Error 1 Marc -- View this message in context: http://www.nabble.com/Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23830861p23851728.html Sent from the Cygwin list 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Sisyphus wrote: Any errors during the 'make test' phase of the Math-GMP-2.05 build ? Yes. Sorry: I forgot about them. I attach the transcript. I couldn't build Net::SSH2... Marc http://www.nabble.com/file/p23852073/mathgmp.test mathgmp.test -- View this message in context: http://www.nabble.com/Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23830861p23852073.html Sent from the Cygwin list 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: Cygwin SSH Multiple Users
Hello, Thanks for the reply. We did play around a lot with ssh-host-config but it used to give errors such that, Win32 error 1062 . Kindly suggest. - Sac -Original Message- From: Georg Nikodym [mailto:geo...@bitmover.com] Sent: Mittwoch, 3. Juni 2009 14:43 To: Holikar, Sachin (ext) Cc: cygwin@cygwin.com Subject: Re: Cygwin SSH Multiple Users On 3-Jun-09, at 4:13 AM, Holikar, Sachin (ext) wrote: Hello, We have configured Cygwin on Windows XP. SOmehow we managed to configure the SSH onto cygwin for a user called mac. We could login to windows XP with the local user name mac and then start the cygwin. And then /usr/sbin/sshd. Its the only way currently how we get to start the sshd daemon. And we could connect from remote system to this XP system using ssh -l mac winxp. But now the problem is we can not make other users login to this winxp host. Here are few of the details help you understand the environment, Consider running the ssh-host-config script. -g -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. How is anybody supposed to know that the file which consists of the single byte 0xa9 has *any* meaning at all? Why should it be the copyright sign, of all things? What I was attempting to do was to have NO conversion. In the real case that I into this, the bug.exe was the one to properly interpret what the byte 0xA9 meant from the command line. Yes, I know there are several workarounds. The command line is always converted to UTF-16 when calling a native Win32 application. If we don't do it (because we call CreateProcessA), Windows would do it. As matters stand, we have to convert ourselves, because we must call CreateProcessW. Either way, the problem persists. We just don't know what the correct conversion is for the given input. We have to rely on a correct setting of $LC_ALL/$LANG/$LC_CTYPE. If we default to the ANSI codepage, you will have the same problem, just upside down. In both cases you will have even more problems if you start using characters not available in your default codepage. This is where I disagreed with Alexey. What we're really arguing here is whether which default will run into the least problems for the most common usage. This is subjective of course. Definitely. The right solution is always only right for a given value of right. What if the user has set LANG to, say, ja_JP.eucJP? That user of course expects that the stuff on the command line is converted to UTF-16 using the eucJP encoding. Everything else would just be very surprising. What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Corinna Vinschen wrote: What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? I'm not clear on what you're proposing here. Are you suggesting that if the conversion from LANG to UTF-16 fails, that we also try a second attempt from the default system code page to UTF-16? -Edward -- 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: OpenSSH server installation error on Windows Vista Business/Ultimate
I have intalled sshd on Vista. The only major (weird) difference I can remember from XP is that you should start your cygwin.bat using Run as an administrator before starting the installation. Being an administrator is not enough, using a default vista installation with user control activated, and the standard vista user control popup does appear to work from within cygwin. (Or you should alternately disable the user control, depending on your security constraints). Hope this helps. Paul August wrote: [snip] I infer from your post that you installed Cygwin using an account other than Administrator. I wouldn't trust it. I suggest: 1. Log on as Administrator. [/snip] -- View this message in context: http://www.nabble.com/OpenSSH-server-installation-error-on-Windows-Vista-Business-Ultimate-tp23708317p23852882.html Sent from the Cygwin list 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Hi. How about the addition of the setting of the locale environment variable (like LANG) to the Cygwin installer? 2009/6/3 Corinna Vinschen corinna-cyg...@cygwin.com: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. How is anybody supposed to know that the file which consists of the single byte 0xa9 has *any* meaning at all? Why should it be the copyright sign, of all things? What I was attempting to do was to have NO conversion. In the real case that I into this, the bug.exe was the one to properly interpret what the byte 0xA9 meant from the command line. Yes, I know there are several workarounds. The command line is always converted to UTF-16 when calling a native Win32 application. If we don't do it (because we call CreateProcessA), Windows would do it. As matters stand, we have to convert ourselves, because we must call CreateProcessW. Either way, the problem persists. We just don't know what the correct conversion is for the given input. We have to rely on a correct setting of $LC_ALL/$LANG/$LC_CTYPE. If we default to the ANSI codepage, you will have the same problem, just upside down. In both cases you will have even more problems if you start using characters not available in your default codepage. This is where I disagreed with Alexey. What we're really arguing here is whether which default will run into the least problems for the most common usage. This is subjective of course. Definitely. The right solution is always only right for a given value of right. What if the user has set LANG to, say, ja_JP.eucJP? That user of course expects that the stuff on the command line is converted to UTF-16 using the eucJP encoding. Everything else would just be very surprising. What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? 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/ -- IWAMURO Motnori http://vmi.jp/ -- 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 SSH Multiple Users
On 3-Jun-09, at 10:10 AM, Holikar, Sachin (ext) wrote: Hello, Thanks for the reply. We did play around a lot with ssh-host-config but it used to give errors such that, Win32 error 1062 . Kindly suggest. To be honest, I don't know. I run ssh-host-config, say yes to privilege separation, give it the cyg_server password when asked (I previously ran cygserver-config). Then I: cygrunsrv -S sshd If I have a problem (like I forgot the cyg_server password), I'll cygrunsrv -R sshd and start again. Also, Win32 error 1062 doesn't tell anybody anything. Paste more of the session to provide some context. -g -- 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/
FAQ 4.46, applications interfere with subversion or not?
Hello, When using cygwin's cvs2svn with subversion (1.6.2 r37639) while running Avira AntiVir (http://www.avira.com/en/pages/index.php), svnadmin is failing sporadically due to permission failure moving files. Reading up on FAQ and mailing lists, I found that 3rd party software like antivirus programs would be the cause. However, I installed subversion for windows from here: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100 (also 1.6.2 r37639), and after modifying cygwin's PATH to use it, the problem went away without touching antivir. I wonder why cygwin's subversion/binaries seems to have issues with antivir, while others do not.. rather looks like a cygwin issue on first glance.. can anyone shed light on this? -Marco -- View this message in context: http://www.nabble.com/FAQ-4.46%2C-applications-interfere-with-subversion-or-not--tp23853503p23853503.html Sent from the Cygwin list 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: Unable to convert postscript to usable form, using either ps2pdf or gs
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of David Karr Sent: Monday, June 01, 2009 2:33 PM To: cygwin@cygwin.com Subject: Unable to convert postscript to usable form, using either ps2pdf or gs I have a generated postscript file (from trueprint) that I need to get into a usable form on Windows, so I can view it and print it. I've tried both ps2pdf and gs, with no success so far. I first tried using ps2pdf. This fails with: --- % ps2pdf tp.ps tp.pdf GPL Ghostscript 8.62: Could not open temporary file /c/DOCUME~1/User/LOCALS~1/Temp/gs_dwvfJL Unable to open the initial device, quitting. --- I have no idea why this matters, but I got this to work by just setting TMPDIR=/tmp (which makes more sense anyway). -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Jun 3 10:43, Edward Lam wrote: Corinna Vinschen wrote: What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? I'm not clear on what you're proposing here. Are you suggesting that if the conversion from LANG to UTF-16 fails, that we also try a second attempt from the default system code page to UTF-16? No. I'm suggesting to convert the command line always using the default ANSI codepage, same as Windows when calling CreateProcessA. This only affects non-Cygwin processes anyway since Cygwin uses another mechanism to send the command line arguments to the child process. 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU On Jun 4 00:03, IWAMURO Motonori wrote: 2009/6/3 Corinna Vinschen What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? How about the addition of the setting of the locale environment variable (like LANG) to the Cygwin installer? I'm sorry, but I don't understand how that's connected to the behaviour of the Cygwin DLL. Setup.exe is an entirely different beast. 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: Cygwin SSH Multiple Users
On Jun 3 11:11, Georg Nikodym wrote: Also, Win32 error 1062 doesn't tell anybody anything. Paste more of the session to provide some context. bash$ net helpmsg 1062 The service has not been started. 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Corinna Vinschen wrote: No. I'm suggesting to convert the command line always using the default ANSI codepage, same as Windows when calling CreateProcessA. This only affects non-Cygwin processes anyway since Cygwin uses another mechanism to send the command line arguments to the child process. Wouldn't that necessarily break non-Cygwin processes that are UTF-16 aware? -Edward -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. The way back was not, AFAIK, needed for Cygwin programs. I don't think there is a valid way back for Windows programs. 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: FAQ 4.46, applications interfere with subversion or not?
On 6/3/2009 8:20 AM, masc wrote: When using cygwin's cvs2svn with subversion (1.6.2 r37639) while running Avira AntiVir (http://www.avira.com/en/pages/index.php), svnadmin is failing sporadically due to permission failure moving files. Reading up on FAQ and mailing lists, I found that 3rd party software like antivirus programs would be the cause. However, I installed subversion for windows from here: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100 (also 1.6.2 r37639), and after modifying cygwin's PATH to use it, the problem went away without touching antivir. I wonder why cygwin's subversion/binaries seems to have issues with antivir, while others do not.. rather looks like a cygwin issue on first glance.. can anyone shed light on this? The subversion code base has some hacks to retry various file operations to work around this issue. These hacks are enabled for a Windows build but not for Cygwin. I've attempted to port these hacks to Cygwin, but I may have missed an error code or three, thus not retrying some errors that should be retried. Are you using Cygwin 1.5 or 1.7? I have disabled this hack in the 1.7 build because I was hoping 1.7's more robust file renaming and deleting code would come to the rescue. If you're using 1.7, I can roll another build with the hack enabled to see if that helps. If you're using 1.5, I'll need your help to debug this so I can adjust the hack to retry in this case. I only see the problem occasionally here. -- David Rothenberger daver...@acm.org Tell the truth and run. -- Yugoslav proverb -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Jun 3 12:02, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. The way back was not, AFAIK, needed for Cygwin programs. I don't think there is a valid way back for Windows programs. The way back is not needed for the argv handling in Cygwin, but it gets necessary if you converted to UTF-16 in other circumstances. It's not much of a problem since the way back is a no-brainer, in contrast to the conversion to UTF-16. 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Jun 3 12:01, Edward Lam wrote: Corinna Vinschen wrote: No. I'm suggesting to convert the command line always using the default ANSI codepage, same as Windows when calling CreateProcessA. This only affects non-Cygwin processes anyway since Cygwin uses another mechanism to send the command line arguments to the child process. Wouldn't that necessarily break non-Cygwin processes that are UTF-16 aware? How? They get the commnd line in UTF-16 anyway. 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Jun 3 18:12, Corinna Vinschen wrote: On Jun 3 12:01, Edward Lam wrote: Corinna Vinschen wrote: No. I'm suggesting to convert the command line always using the default ANSI codepage, same as Windows when calling CreateProcessA. This only affects non-Cygwin processes anyway since Cygwin uses another mechanism to send the command line arguments to the child process. Wouldn't that necessarily break non-Cygwin processes that are UTF-16 aware? How? They get the commnd line in UTF-16 anyway. Ok, I found a problem. Assuming the argument is a valid filename in UTF-8 encoding, as it's the default when using LANG=C. If we try to convert this string using the ANSI codepage, the native child process will get a malformed filename as argument. Looks like always using the ANSI codepage is not exactly a good solution... 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
I think that this problem is caused by missing setting the locale environment variable. Therefore, I think that the problem can be solved by compelling the setting with setup.exe. 2009/6/4 Corinna Vinschen corinna-cyg...@cygwin.com: http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU On Jun 4 00:03, IWAMURO Motonori wrote: 2009/6/3 Corinna Vinschen What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? How about the addition of the setting of the locale environment variable (like LANG) to the Cygwin installer? I'm sorry, but I don't understand how that's connected to the behaviour of the Cygwin DLL. Setup.exe is an entirely different beast. 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/ -- IWAMURO Motnori http://vmi.jp/ -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
And, I think that UTF-8 is best solution when the setting of LC_CTYPE category is C. 2009/6/4 IWAMURO Motonori deenhe...@gmail.com: I think that this problem is caused by missing setting the locale environment variable. Therefore, I think that the problem can be solved by compelling the setting with setup.exe. 2009/6/4 Corinna Vinschen corinna-cyg...@cygwin.com: http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU On Jun 4 00:03, IWAMURO Motonori wrote: 2009/6/3 Corinna Vinschen What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? How about the addition of the setting of the locale environment variable (like LANG) to the Cygwin installer? I'm sorry, but I don't understand how that's connected to the behaviour of the Cygwin DLL. Setup.exe is an entirely different beast. 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/ -- IWAMURO Motnori http://vmi.jp/ -- IWAMURO Motnori http://vmi.jp/ -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod schrieb: Larry Hall (Cygwin) wrote: Try another mirror. It's listed on one or both of the mirrors below: ftp://sourceware.mirrors.tds.net ftp://mirrors.kernel.org OK, Thanks! Got that from the latter. However now that I compile the perl CPAN module: Math::GMP 2.05, I get a lot of compilation errors: gcc -c -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\2.05\ -DXS_VERSION=\2.05\ -I/usr/lib/perl5/5.10/i686-cygwin/CORE GMP.c GMP.c: In function `XS_Math__GMP_destroy': GMP.c:161: warning: cast to pointer from integer of different size ... That's a warning and it is expected, but this is not an error. cygwin has a lot of wrong intsize warnings because we are one of the rare 64bitint platforms, which are mostly untested. You can safely ignore these warnings. For some major packages I try to send patches, but for Math::GMP not yet. rur...@reini ~/.cpan/build/Math-GMP-2.05-9WIuVd $ make test /usr/bin/perl.exe -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/00_signature.skipped: Set the environment variable TEST_SIGNATURE to enable this test t/01_gmppm.ok t/99_perlcriticskipped: Set the environment variable TEST_CRITIC to enable this test t/99_pod...skipped: Set the environment variable TEST_AUTHOR to enable this test t/99_spellcheckskipped: Set the environment variable TEST_SPELL to enable this test t/99_yaml..ok All tests successful. Files=6, Tests=354, 1 wallclock secs ( 0.06 usr 0.03 sys + 0.62 cusr 0.28 csys = 0.99 CPU) Result: PASS -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: FAQ 4.46, applications interfere with subversion or not?
Im using 1.5, will try 1.7 now to see how that goes.. How can I help you to trace it down? David Rothenberger wrote: Are you using Cygwin 1.5 or 1.7? I have disabled this hack in the 1.7 build because I was hoping 1.7's more robust file renaming and deleting code would come to the rescue. If you're using 1.7, I can roll another build with the hack enabled to see if that helps. If you're using 1.5, I'll need your help to debug this so I can adjust the hack to retry in this case. I only see the problem occasionally here. -- View this message in context: http://www.nabble.com/FAQ-4.46%2C-applications-interfere-with-subversion-or-not--tp23853503p23854963.html Sent from the Cygwin list 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: How to change the file mode to link?
No. Shortcuts created with Windows contain more and different information than Cygwin symlinks. If you need a symlink, create it under Cygwin. If I am willing to loose the additional information, is there a way to convert a windows link to a cygwin link? Regards, Peng -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Corinna Vinschen wrote: On Jun 3 12:02, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. The way back was not, AFAIK, needed for Cygwin programs. I don't think there is a valid way back for Windows programs. The way back is not needed for the argv handling in Cygwin, but it gets necessary if you converted to UTF-16 in other circumstances. It's not much of a problem since the way back is a no-brainer, in contrast to the conversion to UTF-16. What is the current state of affairs in cygwin 1.7.0-48? Is the invalid code point solution currently being used when converting the command line to UTF-16 when spawning non-cygwin processes? What I'm trying to understand is where the command line truncation is taking place, in the parent or child process. If the truncation is happening in the child process because of the invalid code point, then perhaps we should consider using the replacement character solution when spawning non-cygwin child processes. IMHO, having a bad character is better than having a truncated command line. At least, the problem (invalid UTF-8) then becomes more obvious. -Edward -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
IWAMURO Motonori wrote: And, I think that UTF-8 is best solution when the setting of LC_CTYPE category is C. 2009/6/4 IWAMURO Motonori deenhe...@gmail.com: I think that this problem is caused by missing setting the locale environment variable. Therefore, I think that the problem can be solved by compelling the setting with setup.exe. That's not a bad idea. I'm thinking of some option in the installer to provide legacy compatibility. -Edward -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Wed, Jun 03, 2009 at 12:55:57PM -0400, Edward Lam wrote: Corinna Vinschen wrote: On Jun 3 12:02, Christopher Faylor wrote: On Wed, Jun 03, 2009 at 04:27:55PM +0200, Corinna Vinschen wrote: On Jun 3 09:18, Edward Lam wrote: Corinna Vinschen wrote: The question is, what do you expect? [...] [...] Wikipedia has several suggestions on how to handle invalid UTF-8 byte sequences (http://en.wikipedia.org/wiki/UTF-8). Personally, I favor the rule that uses the replacement character. Chris implemented using the invalid code point solution. The discussion in http://www.mail-archive.com/linux-u...@nl.linux.org/msg00080.html supports this solution. What's missing so far is the way back, from an invalid single second half of a surrogate pair in the 0xDCxx range back to the correct byte value. I'm just looking into that. The way back was not, AFAIK, needed for Cygwin programs. I don't think there is a valid way back for Windows programs. The way back is not needed for the argv handling in Cygwin, but it gets necessary if you converted to UTF-16 in other circumstances. It's not much of a problem since the way back is a no-brainer, in contrast to the conversion to UTF-16. What is the current state of affairs in cygwin 1.7.0-48? Is the invalid code point solution currently being used when converting the command line to UTF-16 when spawning non-cygwin processes? What I'm trying to understand is where the command line truncation is taking place, in the parent or child process. If the truncation is happening in the child process because of the invalid code point, then perhaps we should consider using the replacement character solution when spawning non-cygwin child processes. IMHO, having a bad character is better than having a truncated command line. At least, the problem (invalid UTF-8) then becomes more obvious. As Corinna said above: Chris implemented using the invalid code point solution That's what is in Cygwin's CVS and in the latest snapshot. 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: Cygwin SSH Multiple Users
On 3-Jun-09, at 11:52 AM, Corinna Vinschen wrote: On Jun 3 11:11, Georg Nikodym wrote: Also, Win32 error 1062 doesn't tell anybody anything. Paste more of the session to provide some context. bash$ net helpmsg 1062 The service has not been started. Awesome! Old dog, new tricks. -g -- 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod schrieb:
Sisyphus wrote:
No error there - just a warning, but that's not going to stop the
compilation and should not be a problem.
Correct, but after I install the result, trying to use it dumps core,
which is why I suspected this (no other errors).
e.g. 'perl Makefile.PL' for Net-SSH-Perl-1.34...
I join a perl.exe.stackdump...
http://www.nabble.com/file/p23850818/perl.exe.stackdump perl.exe.stackdump
Since Math::Pari does not work, you need Math::GMP, right.
But with this and selecting IDEA and Crypt::RSA
I successfully ran all Net-SSH-Perl-1.34 tests.
BTW: for reference the pari error:
gcc-4 -c -I ../pari-2.1.7/src -I../pari-2.1.7/src/headers
-I../pari-2.1.7/src/graph -I. -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-fno-strict-aliasing -pipe -fstack-protector -DUSEIMPORTLIB -O3
-DVERSION=\\ -DXS_VERSION=\\ -Derr=pari_err -DASMINLINE
-DGCC_INLINE -DDYNAMIC_PLOTTING -o mp.o ../pari-2.1.7/src/kernel/none/mp.c
{standard input}: Assembler messages:
{standard input}:4825: Error: suffix or operands invalid for `div'
make[1]: *** [mp.o] Error 1
make[1]: Leaving directory
`/cygdrive/f/cygwin/home/rurban/.cpan/build/Math-Pari-2.010801-Qx0008/libPARI'
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Christopher Faylor wrote: As Corinna said above: Chris implemented using the invalid code point solution That's what is in Cygwin's CVS and in the latest snapshot. I see, you silently committed a fix while this discussion was ongoing? http://www.cygwin.com/snapshots/winsup-changelog-20090530-20090531 -Edward -- 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: FAQ 4.46, applications interfere with subversion or not?
1.7 seems to work well.. imported 8500 revisions on first attempt, while 1.5 was failing each of 5 attempts, never getting beyond rev 600. -- View this message in context: http://www.nabble.com/FAQ-4.46%2C-applications-interfere-with-subversion-or-not--tp23853503p23855609.html Sent from the Cygwin list 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: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Excellent!
Reini Urban wrote:
t/01_gmppm.ok
So this seems to be our only difference.
Math-GMP-2.05 make testdb TEST_FILE=t/01_gmppm.t
/usr/bin/perl.exe -d -Iblib/lib -Iblib/arch t/01_gmppm.t
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
Signal SEGV at blib/lib/Math/GMP.pm line 87
require Math/GMP.pm called at t/01_gmppm.t line 6
main::BEGIN() called at /usr/lib/perl5/5.10/i686-cygwin/DynaLoader.pm
line
0
eval {...} called at /usr/lib/perl5/5.10/i686-cygwin/DynaLoader.pm line 0
This seems to hang below that point...
Line 87 is:
bootstrap Math::GMP $VERSION;
Marc
--
View this message in context:
http://www.nabble.com/Trying-to-install-CPAN-Math%3A%3AGMP.-Can-libgmp3-provide--libgmp--tp23830861p23855706.html
Sent from the Cygwin list 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: Can I install cygwin from my own setup.ini?
Pan ruochen wrote: Hi All, I only want to install the following modules: -- bash base-files sed gawk -- snip I used an extern tool to calculate all the required modules from the basic module set by parsing the download setup.ini file and generate another ini file like: mega-snip which contains only the modules I expect and their required modules. And I replace setup.ini with the created ini file. But it does not seem the replacement take effect. Setup still run as default. Is there any way setup will use download and install modules from my own setup.ini? It is more easy to install cygwin from a simple module list. It's my recollection that you can put the packages that you want in a directory, remove the setup.ini, and Install from Local Directory from setup.exe. I haven't tried this so I can't say that it works for sure but since it's easy to try, you may want to start there. Alternately, you can go the Creating a custom Cygwin package server route found here: http://sourceware.org/cygwin-apps/package-server.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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 change the file mode to link?
Peng Yu wrote: No. Shortcuts created with Windows contain more and different ^^ information than Cygwin symlinks. If you need a symlink, create it under Cygwin. If I am willing to loose the additional information, is there a way to convert a windows link to a cygwin link? Getting rid of the additional information addresses the more part above. You need to handle the different part as well. But why do all that work yourself when ln -s does it for you? OK, let's make this question rhetorical. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Wed, Jun 3, 2009 at 6:27 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: What's left as questionable is the LANG=C default case. Due to the discussion from the last month we now use UTF-8 as default encoding, because it's the only encoding which covers all (valid) characters. Sure, we could also convert the command line using the current ANSI codepage as Windows does it when calling CreateProcessA in this case. Maybe we should do that for testing? Anybody having a strong opinion here? I am strongly against it. Because, as I showed earlier, this case: for filename in `ls`; do windowsprogram.exe $filename end Should work. Since filenames use cygwin's encoding (UTF-8 for C locale, or the value of LANG), arguments conversion should use it too. It would be confusing otherwise. -- 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: [1.7] pthread_mutex_lock/pthread_mutex_unlock strange blocking problem
Thomas Stalder wrote: Hello, Sometimes pthread_mutex_lock ou pthread_mutex_unlock block. Thank you very much for the simple testcases. I have located an invalid racy optimisation in cygwin's internal lock handling that leads to a deadlock owing to unmatched lock acquire/releases, and posted a patch combining that with the fix for the previous deadlock at: http://cygwin.com/ml/cygwin-patches/2009-q2/msg00068.html (As before, I could send you a DLL with the fix compiled in off-list for testing if you like.) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7][BUG] winsup/cygwin/strfuncs.cc
Hi.
I found a trivial bug.
*pmbs is unsigned char.
'\x80' is -128 because it is char literal (not unsigned char).
- *pmbs '\x80' is always true.
# Is not 0x80 but = 0x80 correct?
--- winsup/cygwin/strfuncs.cc 31 May 2009 03:59:38 - 1.30
+++ winsup/cygwin/strfuncs.cc 3 Jun 2009 17:59:23 -
@@ -572,7 +572,7 @@
--len;
}
}
- else if ((bytes = f_mbtowc (_REENT, ptr, (const char *) pmbs,
nms, charset, ps)) 0 *pmbs '\x80')
+ else if ((bytes = f_mbtowc (_REENT, ptr, (const char *) pmbs,
nms, charset, ps)) 0 *pmbs 0x80)
{
/* This should probably be handled in f_mbtowc which can operate
on sequences rather than individual characters.
--
IWAMURO Motnori http://vmi.jp/
--
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 change the file mode to link?
Larry Hall (Cygwin) wrote on Wednesday, June 03, 2009 1:38 PM: Peng Yu wrote: No. Shortcuts created with Windows contain more and different ^^ information than Cygwin symlinks. If you need a symlink, create it under Cygwin. If I am willing to loose the additional information, is there a way to convert a windows link to a cygwin link? Getting rid of the additional information addresses the more part above. You need to handle the different part as well. But why do all that work yourself when ln -s does it for you? OK, let's make this question rhetorical. ;-) If for some reason the OP is going to do this so often that it needs to be automated, one use readshortcut to pull the target for ln -s out of the shortcut. (See also mkshortcut. They are in the cygutils package.) - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: [1.7][BUG] winsup/cygwin/strfuncs.cc
On Jun 4 03:11, IWAMURO Motonori wrote: Hi. I found a trivial bug. *pmbs is unsigned char. '\x80' is -128 because it is char literal (not unsigned char). - *pmbs '\x80' is always true. # Is not 0x80 but = 0x80 correct? You're right. I meant to fix that when I applied the previous patch but then missed it. I applied the = 0x80 condition. Thanks, 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Wed, Jun 03, 2009 at 01:19:45PM -0400, Edward Lam wrote: Christopher Faylor wrote: As Corinna said above: Chris implemented using the invalid code point solution That's what is in Cygwin's CVS and in the latest snapshot. I see, you silently committed a fix while this discussion was ongoing? http://www.cygwin.com/snapshots/winsup-changelog-20090530-20090531 Yes, and then Corinna not-so-silently mentioned it in email that you quoted asking what was going to happen. If you really must know, I was waiting for Corinna to return from vacation before advertising the fix because I wanted her to look at it first before it was exposed to sound and fury of the cygwin mailing list. 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: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On 06/03/2009, Christopher Faylor wrote: If you really must know, I was waiting for Corinna to return from vacation before advertising the fix because I wanted her to look at it first before it was exposed to sound and fury of the cygwin mailing list. Looks like you gotyour wish. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: [1.7] pthread_mutex_lock/pthread_mutex_unlock strange blocking problem
The patchs from DaveK seems to correct all the problems. Thanks to DaveK for his great and quick work. Thomas 2009/6/3 Dave Korn dave.korn.cyg...@googlemail.com: Thomas Stalder wrote: Hello, Sometimes pthread_mutex_lock ou pthread_mutex_unlock block. Thank you very much for the simple testcases. I have located an invalid racy optimisation in cygwin's internal lock handling that leads to a deadlock owing to unmatched lock acquire/releases, and posted a patch combining that with the fix for the previous deadlock at: http://cygwin.com/ml/cygwin-patches/2009-q2/msg00068.html (As before, I could send you a DLL with the fix compiled in off-list for testing if you like.) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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/
Tool equivelent for rundll32.exe user32.dll,LockWorkStation
Is there a tool like shutdown, etc to lock the workstation or should I stick with rundll32.exe user32.dll,LockWorkStation? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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 change the file mode to link?
On Wed, Jun 3, 2009 at 12:37 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Peng Yu wrote: No. Shortcuts created with Windows contain more and different ^^ information than Cygwin symlinks. If you need a symlink, create it under Cygwin. If I am willing to loose the additional information, is there a way to convert a windows link to a cygwin link? Getting rid of the additional information addresses the more part above. You need to handle the different part as well. But why do all that work yourself when ln -s does it for you? OK, let's make this question rhetorical. ;-) Suppose I have many links that are generated by windows already and I want to convert them to cygwin links. To use 'ln -s' I have to have a way to automatically figuring what the target of a window link, but how? Is there such a cygwin command to extract the link from a windows link. Regards, Peng -- 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 change the file mode to link?
Peng Yu writes: Is there such a cygwin command to extract the link from a windows link. Did you not see Barry's response on this thread? ..mark -- 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: Can I install cygwin from my own setup.ini?
I only want to install the following modules: bash base-files sed gawk The easiest way (that I know of, anyway) is to take the existing current setup.ini and insert these lines as the 1st entry under setup-timestamp: setup-version: leaving the rest of setup.ini unaltered. @ anynameyoulike category: Base requires: gawk sed version: 8 (Use any number you like for version but you do need that line.) Now setup your Cygwin using Default. This will install the Cygwin base setup (which includes bash and base-files along with other essentials) and also including your requirements gawk and sed (and any of their requirements). I think you have to accept the Cygwin basic packages as imposed by the Default selection, though they are in fact more numerous than just bash and base-files. HTH Fergus PS In general the entries following requires: in your inserted chunk can be as numerous as you likeor what it's worth I have @ blahblah category: Base requires: bash-completion bc bison expect flex gcc ghostscript gv gnuplot hexedit make nano ncurses readline rxvt tcltk tetex-extra tetex-x11 util-linux vim xpdf xterm version: 8 which leads to a Cygwin installation that *just* fits on to a CD but provides great functionality for technical authoring and text-processing. -- 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: Can I install cygwin from my own setup.ini?
Pan ruochen wrote on Wednesday, June 03, 2009 9:08 AM: I only want to install the following modules: -- bash base-files sed gawk -- But it's an uneasy work to deselect all the unwanted modules from the default status on the cygwin setup dialog box. (And the selection work must be done again every time I invoke setup, if setup failed or I want to add/remove modules). I used an extern tool to calculate all the required modules from the basic module set by parsing the download setup.ini file and generate another ini file like: Editing setup.ini may be more work (and safer) than just using setup without editing setup.ini. Install the first time by using setup (as documented on cygwin.com) to install what you want. When updating, just keep on clicking on Next until you arrive at OK (then click on OK). When updating, you can see what will be updated: in the package chooser screen, click on the View button until you get the Partial view. Or you can update with setup's unattended mode. Here is what I use. Documentation is in the archives and on cygwin.com. c:\cygwin\usr\local\bin\setup.exe -R c:\cygwin -n -q -l h:\cygwin\arc Good luck, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: UAC .manifest files
On 03/06/2009 03:11, Corinna Vinschen wrote:
I never saw more than exactly this list.
Got it (and with instal with one L).
I don't know if it matters, but it certainly doesn't hurt either. As a
suggestion, when automating this, the name could be constructed like
this:
Organization=Cygwin
Division=packagename
Name=executable
As for why, IIRC you mentioned[1] before that the manifests are cached;
I suppose the name= attribute would be used in the cached data, hence
the requirement to be unique.
Some additional googling revealed that you also mentioned that the
manifests need to be executable[2].
The attached patch is what I have in mind. It won't apply to SVN trunk
yet due to other uncommitted patches in the queue, but I need to fix
that soon to get a long-overdue release out the door. Anything else
that I may not be aware of before I commit this?
[1] http://www.cygwin.com/ml/cygwin/2008-11/msg00163.html
[2] http://www.cygwin.com/ml/cygwin-apps/2008-08/msg00148.html
Yaakov
Index: bin/cygport.in
===
--- bin/cygport.in (revision 6306)
+++ bin/cygport.in (working copy)
@@ -1123,6 +1156,7 @@
# __prepinfo
# __prepman
# __prepstrip
+# __prepuac
# __prepvargames
# __prep_empty_dirs
# __prep_libtool_modules
@@ -1371,13 +1419,8 @@
# *.so: Apache2 modules, OCaml stublibs, Ruby modules
# *.oct: Octave modules
- for exe in $(find * -type f -name '*.dll' -o -name '*.exe' -o -name
'*.so' -o -name '*.oct')
+ for exe in $(find * -type f -writable -a \( -name '*.dll' -o -name
'*.exe' -o -name '*.so' -o -name '*.oct' \))
do
- if [ ! -w ${exe} ]
- then
- continue
- fi
-
# OCaml bytecode must not be stripped
# this test generates false positives with the ocaml core and
# compilers, but should otherwise be accurate
@@ -1404,6 +1447,29 @@
done
}
+__prepuac() {
+ local exe exename;
+
+ cd ${D};
+
+ echo Preparing executables for UAC:;
+
+ for exe in $(find * -type f -executable -a \( -name '*instal*.exe' -o
-name '*patch*.exe' -o -name '*setup*.exe' -o -name '*update*.exe' \))
+ do
+ exename=${exe##*/};
+
+ # Mono assemblies may already include .manifest files.
+ if [ ! -e ${exe}.manifest ]
+ then
+ echo ${exe};
+ sed -e s|@PKGNAME@|${PN//.}| \
+ -e s|@APPNAME@|${exename%.exe}| \
+ ${_privdatadir}/uac-manifest.in
${exe}.manifest
+ chmod +x ${exe}.manifest
+ fi
+ done
+}
+
__prep_symlinks() {
local l l_src
@@ -1443,12 +1504,13 @@
__prepvargames;
__prep_empty_dirs;
__prepstrip;
+ __prepuac;
__prep_libtool_modules;
}
# protect functions
readonly -f __prepdoc __prepetc __prepman __prepinfo __prepvargames
__prep_empty_dirs \
-__prepstrip __prep_symlinks __prep_libtool_modules __src_postinst
+__prepstrip __prepuac __prep_symlinks __prep_libtool_modules
__src_postinst
Index: data/Makefile.am
===
--- data/Makefile.am(revision 6446)
+++ data/Makefile.am(working copy)
@@ -1,4 +1,8 @@
-dist_pkgdata_DATA = cygport.nanorc mirrors sample.cygport
+dist_pkgdata_DATA = \
+ cygport.nanorc \
+ mirrors \
+ sample.cygport \
+ uac-manifest.in
bashcompletiondir = /etc/bash_completion.d
dist_bashcompletion_DATA = cygport-bash-completion
Index: data/uac-manifest.in
===
--- data/uac-manifest.in(revision 0)
+++ data/uac-manifest.in(revision 0)
@@ -0,0 +1,16 @@
+?xml version=1.0 encoding=UTF-8 standalone=yes?
+assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0
+ assemblyIdentity version=1.0.0.0
+ processorArchitecture=X86
+ name=cygw...@pkgname@@appname@
+ type=win32/
+
+ !-- Identify the application security requirements. --
+ trustInfo xmlns=urn:schemas-microsoft-com:asm.v3
+security
+ requestedPrivileges
+requestedExecutionLevel level=asInvoker uiAccess=false/
+ /requestedPrivileges
+/security
+ /trustInfo
+/assembly
--
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: Re: Trying to install CPAN Math::GMP. Can libgmp3 provide -libgmp?
Marc Girod marc.gi...@gmail.com wrote: SSH2.xs:581: error: `LIBSSH2_VERSION_NUM' undeclared (first use in this function) Without checking, I think it's just that the version of libssh2 is too old for Net-SSH2-0.20. Net-SSH2-0.20 should build against libssh2 versions 0.19 and 1.0. What version of the library do you have ? You should be able to build libssh2-1.0 from source, if the binary being distributed by cygwin is too old ... it's just a question of how many different roads you want to investigate, and how far down those different roads you're prepared to travel :-) Cheers, Rob -- 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/
Combining -D and -L on setup command line
I had the opportunity to test the latest cygwin-1.7 today after my USB stick got trashed. Using setup 2.625 the combination of -D -L on the command line does not result in the expected download and install operation. I have to run setup twice, once with -D to download to pull the files into a local directory, and then with -L to do the actual install from the local directory. I see that the patch to support both is in CVS as version 2.18.6.1 but not in 2.19 (HEAD) Is this an oversight or do I just need to wait until the streams get merged? Cheers, Ralph -- 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: Can I install cygwin from my own setup.ini?
Or you can just use the -P option from the setup command line and get exactly the packages you want! Ralph -- 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: Combining -D and -L on setup command line
On Wed, Jun 03, 2009 at 09:37:09PM -0400, Ralph Hempel wrote: I had the opportunity to test the latest cygwin-1.7 today after my USB stick got trashed. Using setup 2.625 the combination of -D -L on the command line does not result in the expected download and install operation. I have to run setup twice, once with -D to download to pull the files into a local directory, and then with -L to do the actual install from the local directory. I see that the patch to support both is in CVS as version 2.18.6.1 but not in 2.19 (HEAD) Is this an oversight or do I just need to wait until the streams get merged? It's an oversight. What is the ChangeLog entry for this change? 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/
