Re: awk gsub problem
On Sep 17 22:30, Lee wrote:
> On 9/16/10, Corinna Vinschen wrote:
> > On Sep 15 18:30, Lee wrote:
> >> I don't know if this is just a problem with the cygwin version of awk,
> >> me misunderstanding something or what, but it looks like gsub isn't
> >> working correctly in awk:
> >> $ sh /tmp/test.awk
> >> s= ::0:: should = ::S0::
> >>
> >> $ cat /tmp/test.awk
> >> awk '
> >> BEGIN {
> >> s="Serial0"
> >> gsub("[a-z]","",s)
> >> printf("s= ::%s:: should = ::S0::\n", s)
> >> exit
> >> } '
> >>
> >> I also tried it with IGNORECASE=0 and with "awk --traditional" - same
> >> results.
> > Works fine for me:
>
> Comment out the 'set LANG=" and gsub works fine:
> $ echo $LANG
> C.UTF-8
>
> $ sh /tmp/test.awk
> s= ::S0:: should = ::S0::
>
> $ export LANG=en_US.UTF-8
>
> $ sh /tmp/test.awk
> s= ::0:: should = ::S0::
>
> So awk gsub works for me again - thank you!
>
> Just out of curiosity, why would setting LANG to en_US break
> case-sensitivity in gsub?
I don't know either. I just asked the upstream maintainer. At least it
isn't a Cygwin problem, since it also behaves the same on Linux.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: distro "apache2" will not start
On Sep 17 16:14, David Rothenberger wrote: > On 9/17/2010 3:16 PM, Yaakov (Cygwin/X) wrote: > > On Fri, 2010-09-17 at 09:37 +0200, Corinna Vinschen wrote: > >> The apache2 package is orphaned for this long period of time already. > >> Maybe it's time to pull it from the distro, unless somebody would > >> like to take over maintainership. > > > > Apache2 is too important to lose from the distro, so: > > > > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/apache2 > > > > I'm AFK until Sunday, so that's the best I can do right now. > > I'll continue to include subversion-apache2 in my releases until apache2 > is actually removed (if ever). I've confirmed I can build subversion > without apache2 and can do some testing of the http client with a native > apache2/subversion server, so I'm good to go either way. If apache2 is > ever removed, just remove subversion-apache2 as well and I'll adjust on > my next release. I'm not going to remove anything until this is settled. It's just sad that almost every time we need a package maintainer, it's Yaakov who has to step up. Yaakov is an excellent package maintainer but there's only so much a single person can do and Yaakov already maintains hundreds of packages. If there's anybody here who would like to contribute to this project, please give the idea to maintain a Cygwin package a whirl. Especially taking over maintainership of an orphaned package would be very helpful for the community as a whole. For a start, see http://cygwin.com/setup.html and the "ORPHANED" packages in the text file http://cygwin.com/cygwin-pkg-maint Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Instead of a gripe, a memory-jog.
Having recently by accident trashed my home folder, and having had to
rebuild from one saved from a much older install (1.7.0 or even
earlier), I noticed my man pages were again displaying with garbage text
in between the readable text -- nonprintable characters, Unicode litter
and the like. I remembered Corinna Vinschen had posted something quite a
while back in a topic thread that dealt with this issue; I am sure it
made it into the archives for this list, but I wasn't able to find it. I
vaguely recalled one detail had something to do with setting one's
environment variable to C instead of C.utf_8 or even en_us.utf8. So
just as a trial-and-error, not-so-monstrous-it-cant-be-changed-back sort
of thing, I tried it and opened the man page for an application that
didn't come from any of the usual places (at least not in the version or
build I happen to be running) and it worked like a charm. Now I just
have to *string around the finger time* remember to change the LANG line
in System>Advanced>Environment Variables {or its alternate route via My
Computer, which I'm sure most of you know} to the same thing.
Plain old *C*. Whowuddathottitt?
Steve Wright
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Testing: mintty-0.9b1-1
mintty 0.9b1-1 is on its way to the Cygwin mirrors. This is a test release.
To install it using setup.exe, find mintty on the package selection
screen and click on the cycle symbol by its version number until the
required version appears. Make sure the checkbox in the 'Bin?' column
next to it is ticked.
Alternatively, just click on the 'Exp' button at the top of the
package selection screen to install available test versions of all
installed packages, thereby helping to make sure they're stable.
Otherwise, a .zip can be downloaded from http://mintty.googlecode.com.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
CHANGES
===
Display issues:
- On multimonitor systems, the window size is no longer limited to the
size of a single monitor.
- The program window should no longer be opened with parts off the
screen or obscured by the taskbar (unless of course the window is too
big too fit into the available workspace).
- Fixed an issue with cursor flicker on Vista and 7 with Aero disabled.
- The options dialog no longer flashes when changing page while
transparency is enabled, as happened on non-Aero systems.
Colours:
- Added ability to set the 16 ANSI colours in the config file (or on
the command line via the -o option), like so: 'Blue=0,0,255' or
'BoldGreen=128,255,128'. The manual has all the colour names.
- Added ability to switch cursor colour depending on whether the Input
Method Editor (IME) is active. This is activated by setting
'IMECursorColour' in the config file (or via the -o option). So, for
example, adding 'IMECursorColour=255,0,0' to ~/.minttyrc will turn the
cursor red when the IME is active. (IMEs allow entering characters
that aren't on the keyboard and are crucial for East Asian languages.)
- Renamed 'Show bold is bright' setting to 'Show bold as colour'.
- Removed the 'Use system colours instead' checkbox from the options
dialog. The 'UseSystemColours' config file setting remains.
Selection:
- Added config-file only 'WordChars' setting for controlling the
characters selected by a double click. By default, mintty uses an
algorithm that's geared towards picking out filenames and URLs. If
'WordChars' is set, that algorithm is disabled, and instead only
letters, digits, and the characters specified with this setting are
selected. For example, setting 'Wordchars=_' would ensure that C
identifiers are picked out correctly.
- Fixed a crash that occurred when copying lots of text on systems
with a doublebyte default codepage.
Xterm compatibility:
- Added support for xterm's VT220-style function key mode (as opposed
to the default "PC-style" keycodes), where Ctrl+F3 through Ctrl+F10
act as F13 through F20, the Home and End keys send different keycodes,
and the numpad sends "application keypad" codes if enabled with the
DECPAM sequence.
- In mouse tracking mode, concurrent mouse button presses are now
handled in the same way as they are in xterm, i.e. mintty no longer
sends a fake mouse release event when the second button is pressed.
- 'Extended Mouse Mode' as introduced in xterm #262 is now supported.
This allows row/column positions greater than 255 (and up to 2015) to
be reported, in case you do get that 30'' monitor ...
Misc:
- Alt+F4 prompts for exit confirmation if the shell has any child
processes, as already happens with the close button. (There's an
option for disabling this.)
- Added a tip to the manual on how to use Ctrl[+Shift]+Tab to switch
session in GNU screen.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'), and it's
also available in PDF format at
http://mintty.googlecode.com/files/mintty-0.9-beta1.pdf.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list. Please use the issue tracker at
http://code.google.com/p/mintty/issues/list to report bugs or suggest
enhancements.
To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsu
Re: Instead of a gripe, a memory-jog.
On Sep 18 07:00, SJ Wright wrote: > Having recently by accident trashed my home folder, and having had > to rebuild from one saved from a much older install (1.7.0 or even > earlier), I noticed my man pages were again displaying with garbage > text in between the readable text -- nonprintable characters, > Unicode litter and the like. I remembered Corinna Vinschen had > posted something quite a while back in a topic thread that dealt > with this issue; I am sure it made it into the archives for this > list, but I wasn't able to find it. I vaguely recalled one detail > had something to do with setting one's environment variable to C > instead of C.utf_8 or even en_us.utf8. Ouch. Wrong on both accounts. Either "C.UTF-8, or "C.utf-8", or "C.utf8", or "en_US.UTF-8" or "en_US.utf-8" or "en_US.utf8". Dash yes, underscore no. The territory must be written in uppercase. The User's Guide might be a good start: http://cygwin.com/cygwin-ug-net/setup-locale.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
On 9/17/10, SJ Wright wrote: > > 4. Is it normal for any script to run CPU usage up to 100%? Unless it is blocking for something like IO including VM swaps, why not? > > Regarding #4: > I have a script that I ran in GNOME Terminal less than an hour ago. I > "time"d it -- the return was 20.6 seconds on the first line (real?). I > ran the same script fifteen minutes later, evaluating identical files of > the same type, length (5.37kb and 345b ASCII text) and time stamp, and > after 7 minutes it was barely one-eighth complete. That's when I checked > Task Manager and found my CPU usage was at 100% and three bash.exe's > were running simultaneously. Admittedly the script calls on several This sounds like a threading problem if I had to guess but it could be anything that changed between runs- certainly timing will make these things come and go but having no idea what you mean by identical instead of "the same" there are a lot of things that could have changed etc. What did it seem to be trying to do? Often in cases like this the alarming situation is where your cpu usage drops to low values and your disk light gets stuck on as you have depleted memory. I guess I'm also not sure what you think a usual or good number of processes should be etc. A number of anecdotes have been reported about slower performance on 64 bit or multi core machines than more primitive older cmoputers and it is easy to speculate on reasons why that could happen but hard to make a clear diagnosis without an explicit test case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unacceptable behavior -- slowing down script execution
Cyrille Lefevre wrote: Le 17/09/2010 18:57, SJ Wright a écrit : 4. Is it normal for any script to run CPU usage up to 100%? a common answer about bash cpu usage is to get rid of bash-completion... if you have it installed, uninstall it, then try again. Regards, Cyrille Lefevre Thank you, Cyrille. It seems to have worked. Is there any reason, when bash itself nowadays has pretty good tab-completion, why bash-completion is still available in setup.exe or elsewhere in the Luniverse? At any rate, some effort should be made to inform new folks (to GNU-stuff) about the differences between them, and recommend against installing it -- or anything that depends on it (git-completion, acc'd. to the latest setup utility) -- if they're not going to need it for whatever they've installed Cygwin for. Something like this should be in big bold letters in the setup guide pages -- something giving the sense of "bash-completion is more than tab-completion: don't confuse the two." Enough tripping off through the garden of Tangent. Cheers. Steve Wright -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git and ssh issue
On 09/18/2010 12:23 AM, Frédéric Bron wrote: > using cygwin 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 > > I have right now an example where I cannot fetch with the following > error message: > > remote: Counting objects: 534, done. > remote: Compressing objects: 100% (210/210), done. > fatal: The remote end hung up unexpectedly > fatal: early EOFs: 39% (141/359) > fatal: index-pack failed > > The repository contains proprietary data so that it cannot be accessed > from somebody else but is there still anything I could do that would > help to debug this now long standing issue? I am still using 1.5 for > production because of this and I would be very much pleased to switch > entirely to 1.7! We have actually found a publicly available repository and a simple scenario which reliably reproduces this problem: http://cygwin.com/ml/cygwin/2010-07/msg00505.html Unfortunately, it doesn't look like anyone has the time to dig deep into this yet. As you'll see in that thread, you can use Putty's plink instead of ssh to handle the remote connections while you wait for a fix. At least you'll be able to take advantage of all the other Cygwin improvements in the meantime. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: distro "apache2" will not start
On Sat, Sep 18, 2010 at 11:34:05AM +0200, Corinna Vinschen wrote: >On Sep 17 16:14, David Rothenberger wrote: >> On 9/17/2010 3:16 PM, Yaakov (Cygwin/X) wrote: >> > On Fri, 2010-09-17 at 09:37 +0200, Corinna Vinschen wrote: >> >> The apache2 package is orphaned for this long period of time already. >> >> Maybe it's time to pull it from the distro, unless somebody would >> >> like to take over maintainership. >> > >> > Apache2 is too important to lose from the distro, so: >> > >> > http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/apache2 >> > >> > I'm AFK until Sunday, so that's the best I can do right now. >> >> I'll continue to include subversion-apache2 in my releases until apache2 >> is actually removed (if ever). I've confirmed I can build subversion >> without apache2 and can do some testing of the http client with a native >> apache2/subversion server, so I'm good to go either way. If apache2 is >> ever removed, just remove subversion-apache2 as well and I'll adjust on >> my next release. > >I'm not going to remove anything until this is settled. > >It's just sad that almost every time we need a package maintainer, it's >Yaakov who has to step up. Yaakov is an excellent package maintainer >but there's only so much a single person can do and Yaakov already >maintains hundreds of packages. > >If there's anybody here who would like to contribute to this project, >please give the idea to maintain a Cygwin package a whirl. Especially >taking over maintainership of an orphaned package would be very helpful >for the community as a whole. > >For a start, see http://cygwin.com/setup.html and the "ORPHANED" packages >in the text file http://cygwin.com/cygwin-pkg-maint Corinna forgot to mention that, if you pick up an orphaned package, you get a big gold star at http://cygwin.com/goldstars/ . It's hard to imagine why that, in itself, isn't adequate motiviation for anyone. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
>> A second thought. I wonder if reabaseall could be improved to run from >> within bash, without the need to close down all running windows. Then >> it could even be included into build scripts to be run after each >> build. > > No, because the DLLs used by bash are OFTEN the ones that actually DO > need to be rebased (because they are used by darn near everything, so we > need to ensure that their image base does not conflict with anything > else): libintl, libiconv, libncurses, ... > What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. I try to be more precise. Let's call it rebaseplus, but it's code is to 80% similar to rebaseall and duplication of code has known disadvantages. Once rebaseall has been run from ash we can be sure the listed DLLs have sane addresses and bash does work. Now rebaseplus can be run from within bash (and scripts) using a user contributed list of DLL (-T-option). It would base the user contributed DLL into a different address space than rebaseall does. Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: awk gsub problem
On Sep 18 11:21, Corinna Vinschen wrote:
> On Sep 17 22:30, Lee wrote:
> > On 9/16/10, Corinna Vinschen wrote:
> > > On Sep 15 18:30, Lee wrote:
> > >> I don't know if this is just a problem with the cygwin version of awk,
> > >> me misunderstanding something or what, but it looks like gsub isn't
> > >> working correctly in awk:
> > >> $ sh /tmp/test.awk
> > >> s= ::0:: should = ::S0::
> > >>
> > >> $ cat /tmp/test.awk
> > >> awk '
> > >> BEGIN {
> > >> s="Serial0"
> > >> gsub("[a-z]","",s)
> > >> printf("s= ::%s:: should = ::S0::\n", s)
> > >> exit
> > >> } '
> > >>
> > >> I also tried it with IGNORECASE=0 and with "awk --traditional" - same
> > >> results.
> > > Works fine for me:
> >
> > Comment out the 'set LANG=" and gsub works fine:
> > $ echo $LANG
> > C.UTF-8
> >
> > $ sh /tmp/test.awk
> > s= ::S0:: should = ::S0::
> >
> > $ export LANG=en_US.UTF-8
> >
> > $ sh /tmp/test.awk
> > s= ::0:: should = ::S0::
> >
> > So awk gsub works for me again - thank you!
> >
> > Just out of curiosity, why would setting LANG to en_US break
> > case-sensitivity in gsub?
>
> I don't know either. I just asked the upstream maintainer. At least it
> isn't a Cygwin problem, since it also behaves the same on Linux.
I got reply from the upstream maintainer. Case-sensitivity in gsub is
not broken, rather it's really a language dependent difference.
If LANG is "en_US" or "en_US.utf8", then the regular expression "[a-z]"
does *not* correspond anymore to the ASCII codes. Rather it corresponds
to something like "[aAbBcCdD...zZ]", independent of the actual character
encoding ISO-8859-1 or UTF-8.
What you really want is this:
BEGIN {
s="Serial0"
gsub("[[:lower:]]","",s)
printf("s= ::%s:: should = ::S0::\n", s)
exit
}
The "[[:lower:]]" expression always catches all valid lowercase letters,
independent of the langauge, territory, and charset used.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git and ssh issue
The test case works just fine for me: Windows 7 latest git and openssh cygwin 1.7.7-1 I wonder if it's an OS-specific or BLODA problem? Regards -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
On Sat, Sep 18, 2010 at 08:36:28PM +0200, Al wrote: >>> A second thought. I wonder if reabaseall could be improved to run from >>> within bash, without the need to close down all running windows. Then >>> it could even be included into build scripts to be run after each >>> build. >> >> No, because the DLLs used by bash are OFTEN the ones that actually DO >> need to be rebased (because they are used by darn near everything, so we >> need to ensure that their image base does not conflict with anything >> else): libintl, libiconv, libncurses, ... >> > >What I suggest isn't that usefull when you think to base all >DLL that have been installed by setup.exe. It becomes usefull in the >moment the user starts to compile his own DLL especially if he used >scripts to control compilation. To compile somethng is a typical use >of cygwin. No, it really isn't. >I try to be more precise. Let's call it rebaseplus, but it's >code is to 80% similar to rebaseall and duplication of code has known >disadvantages. > >Once rebaseall has been run from ash we can be sure the listed DLLs >have sane addresses and bash does work. Now rebaseplus can be run from >within bash (and scripts) using a user contributed list of DLL (-T-option). >It would base the user contributed DLL into a different address space than >rebaseall does. This isn't a bad idea but it's not really a typical use case. Perhaps you'd like to offer a patch to rebaseall to accomplish this? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin + Python: unable to remap
Al schrieb: Or, read from stdin as follows: $ "something that generates extra DLL list" | rebaseall -T - ... As example, "something that gernates extra DLL list" looks in my case like this. PREFIX=/home/prefix/gentoo find $PREFIX/bin/ -name *.dll -o -name *.so find $PREFIX/lib/ -name *.dll -o -name *.so find $PREFIX/usr/bin -name *.dll -o -name *.so find $PREFIX/usr/lib -name *.dll -o -name *.so It turned out that not all files have write access. So a similar script is required to add write access first. You should really check out /bin/perlrebase which is a simple application of a perl-based rebaseall with -T and more. For python you might need to write a similar script. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
>>scripts to control compilation. To compile somethng is a typical use >>of cygwin. > > No, it really isn't. I quote wikipedia: Cygwin is used heavily for porting many popular pieces of software to the Windows platform. It is used to compile Sun Java, OpenOffice.org, and even server software, like lighttpd. If that isn't valid any more, it's time to update the article. > > This isn't a bad idea but it's not really a typical use case. Perhaps you'd > like to offer a patch to rebaseall to accomplish this? > Sure I offer a patch. Else I wouldn't come up with a suggestion. I need to work on that anyway. Al -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
On Sun, Sep 19, 2010 at 12:43:17AM +0200, Al wrote: >On Sat, Sep 18, 2010 at 05:48:07PM -0400, Christopher Faylor wrote: >>>scripts to control compilation. To compile somethng is a typical use >>>of cygwin. >> >> No, it really isn't. > >I quote wikipedia: > >Cygwin is used heavily for porting many popular pieces of software to >the Windows platform. It is used to compile Sun Java, OpenOffice.org, >and even server software, like lighttpd. > >If that isn't valid any more, it's time to update the article. Maybe this will help: http://cygwin.com/dontbelieveeverythingyoureadonrandomsitesaboutcygwin.html cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git and ssh issue
On 09/18/2010 04:16 PM, Eliot Moss wrote: > The test case works just fine for me: > > Windows 7 > latest git and openssh > cygwin 1.7.7-1 > > I wonder if it's an OS-specific or BLODA problem? My system doesn't have anything from the BLODA list on it, and Chris was able to reproduce the problem as well. It's possible that this might be some sort of race condition, and maybe faster machines such as yours are less affected. Maybe it's also possible that the latest Cygwin update has made the problem less easily reproducible. I'll make sure my system is updated and try this again on Monday when I get into work. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
- Original Message - From: "Christopher Faylor" What I suggest isn't that usefull when you think to base all DLL that have been installed by setup.exe. It becomes usefull in the moment the user starts to compile his own DLL especially if he used scripts to control compilation. To compile somethng is a typical use of cygwin. No, it really isn't. I'd beg to differ; I'd suggest it is, as suggested by the OP, actually quite a common use. You only have to look at the use of say perl and you will have users quite regularly compiling their own DLL's as they install modules via CPAN, and this is quite painful due to all the issues it can present with rebase. While I love cygwin, I must say that its supporting community can be very dismissive of its users to the point of alienating potential contributors. I myself has have experienced this on several occasions and have ended up finding myself not raising issues that affect us daily for fear of being shot down for no more reason that someone doesn't "think" its import to fix or should "work" that way anyway or even doesn't like the way you structured you post. To reiterate I still think that developers deserve much respect and thanks for all the effort they put in, but a little more open mindedness and approachability like that which can be found in other open source communities such as SFU and FreeBSD wouldn't go a miss sometimes ;-) Regards Steve -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simplifying rebaseall
On Sun, Sep 19, 2010 at 03:52:56AM +0100, Steven Hartland wrote: >- Original Message - >From: "Christopher Faylor" > >>>What I suggest isn't that usefull when you think to base all >>>DLL that have been installed by setup.exe. It becomes usefull in the >>>moment the user starts to compile his own DLL especially if he used >>>scripts to control compilation. To compile somethng is a typical use >>>of cygwin. >> >> No, it really isn't. >> >> This isn't a bad idea but it's not really a typical use case. ?Perhaps you'd >> like to offer a patch to rebaseall to accomplish this? > >I'd beg to differ; I'd suggest it is, as suggested by the OP, >actually quite a common use. You only have to look at the use of >say perl and you will have users quite regularly compiling their >own DLL's as they install modules via CPAN, and this is quite painful >due to all the issues it can present with rebase. We have different definitions of the term "typical". The vast VAST majority of people who use Cygwin do not build their own DLLs but they are likely to run into rebase problems. >To reiterate I still think that developers deserve much respect >and thanks for all the effort they put in, but a little more open >mindedness and approachability like that which can be found in other >open source communities such as SFU and FreeBSD wouldn't go a miss >sometimes ;-) You are responding, for some reason, to one line where I said "No, it really isn't" and ignoring the rest of the message where I suggested that the OP could provide a patch and they even said they were going to do so. This is pretty typical Cygwin mailing list behavior: ignore the substance and focus on the indignation. It's hardly helpful and it doesn't really get the problem solved. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
