Re: cyg1.7 - DOS character remapping: change request.
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Linda Walsh on 11/23/2009 4:59 PM:
Instead of using random characters out of the 'random free area' --
which could display as anything if you aren't in cygwin, depending
on what charset you have loaded, why not use 'dedicated' unicode
characters that map to the signs for those characters? They aren't
exactly equivalent, as they include some built-in display spacing,
BUT, they would display a colon as a colon, "*" as a asterisk, etc.
But then, how would you distinguish between the valid UTF-16 replacement
used to represent an invalid character, and a valid UTF-16 character
representing itself? I'm sorry, but the value of a 1-to-1 round trip
mapping outweighs the convenience of displaying a glyph that looks the
same but causes ambiguous round trip conversions.
You've already broken 1-to-1 round trip compatibility by NOT
using an **INVALID** UTF-16 character. You are using "the 0xf000-0xf0ff
range. This range is part of the UNICODE block 95, "Private Use Area".
These are *valid* unicode characters -- they are just NOT reserved for
a particular application. This means they will be displayed randomly
and CAN be used by other applications (Mathematica for more than one of
it's character sets). IF you had used something that was NOT valid unicode,
you'd be safe. But the private use area IS valid, usable, area that is
already in use by other applications. You are 'illusioned' if you think
cygwin can use those characters without conflict. (I hate disillusioning
people...they usually don't like it, likely due to my great skill in the
area of 'tact'(!*sigh*!)).
This being the case, using characters that *are* reserved
for displaying the characters cygwin needs ("*:<>|?), makes sense. No
one will be using those characters for something other than to display
those 7 characters.
Those are "display forms" of those characters -- used for
displaying those characters when the actual characters can't or aren't
usable due to encoding issues.
That pretty much sums up how Cygwin is using them. In order to
not break other applications and standards, I strongly urge you to consider
using the allocated forms for the 'display' versions of the characters
you are using. There should be absolutely no breaking in compatibility.
Since anyone using those in a filename would be trying to get exactly the
effect Cygwin is wanting -- something that displays as those characters, but
isn't treated as those characters semantically.
This is coming from someone who DOES use those characters, and I know
that if cygwin treated them as standard characters (converting them to their
ASCII equivalents) in programs, it wouldn't break anything- because those
are all generic filename characters).
Your argument of trying not to break 1:1 roundtrip compatibility is
specious as it's simply broken already, as you are using characters that many
fonts use. I have a few thousand fonts, and a surprising number use that area
for storing alternative glyphs. You are more likely to encounter a conflict
using something that is documented to be usable by anyone for anything, than
if you use characters that are documented to be used exactly for the purpose
cygwin is using them.
-l
--
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: cyg1.7 - DOS character remapping: change request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 11/23/2009 4:59 PM: > Instead of using random characters out of the 'random free area' -- > which could display as anything if you aren't in cygwin, depending > on what charset you have loaded, why not use 'dedicated' unicode > characters that map to the signs for those characters? They aren't > exactly equivalent, as they include some built-in display spacing, > BUT, they would display a colon as a colon, "*" as a asterisk, etc. But then, how would you distinguish between the valid UTF-16 replacement used to represent an invalid character, and a valid UTF-16 character representing itself? I'm sorry, but the value of a 1-to-1 round trip mapping outweighs the convenience of displaying a glyph that looks the same but causes ambiguous round trip conversions. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksLVDIACgkQ84KuGfSFAYCAMACgqj76FkhwHf6jLa2lG7ohZind iB8AoLWCl5VNJXmQ6MNOybP0LCXqZ4qT =icUw -END PGP SIGNATURE- -- 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
ssh and scp connect intermittently
Hi, I have cygwin installed on several WindowsXP systems. When trying to use ssh or scp to connect or send files to a remote system, the commands usually work the first few times but then they reliably hang. The problem I am having is exactly the same as one that was reported on this list about a month ago: http://cygwin.com/ml/cygwin/2009-09/msg00069.html The previous thread ended without a solution being posted. Has anyone looked into this problem? Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cyg1.7 - DOS character remapping: change request.
Was thinking about a 1 or 2 mods for the new characters that are being remapped to the 'private area', but also a compatibility bug. Maybe I'll get the bug out of the way first. Filenames created on a samba share are not visible on the server as anything resembling what I used on Cygwin. I see that as pretty bad (scale 1-10, maybe a 7). One possible way to ameliorate that problem is in first suggestion I thought of. Instead of using random characters out of the 'random free area' -- which could display as anything if you aren't in cygwin, depending on what charset you have loaded, why not use 'dedicated' unicode characters that map to the signs for those characters? They aren't exactly equivalent, as they include some built-in display spacing, BUT, they would display a colon as a colon, "*" as a asterisk, etc. There are reserved and 'fullwidth' forms of each of the characters that need remapping. The fullwidth forms add some visual space around the characters though it's still only 1 Unicode character. The mappings I'd suggest as default mappings are as follows: dosch U-char Unicode-val ;Unicode Comment " ＂ U+FF02 ;FULLWIDTH QUOTATION MARK * ＊ U+FF0A ;FULLWIDTH ASTERISK : ： U+FF1A ;FULLWIDTH COLON <＜ U+FF1C ;FULLWIDTH LESS-THAN SIGN >＞ U+FF1E ;FULLWIDTH GREATER-THAN SIGN ? ？ U+FF1F ;FULLWIDTH QUESTION MARK | ｜ U+FF5C ;FULLWIDTH VERTICAL LINE --- All of the above are the 'FULLWIDTH' versions of each of those characters. They aren't a perfect substitute, as they don't have the same ascii values, and, correctly implemented, they will display a bit of extra white space around the char. But on the positive side -- and important for unicode parsing, __each of the fullwidth forms has the same character class as its ascii equivalent__. So the full width quote has the property 'quotation mark'. So if the name was read by a unicode capable program (like perl), it could process the special characters in whatever way it would have processed the real ascii character. The other benefit is that a great many unicode charsets have mappings for the full width forms. Whatever charset I'm using -- they all displayed as what they are (with slight stylistic variations). They also displayed in my shell client on linux as their ascii equivalents and displayed in 3 windows command line clients I tried (Console2, mintty, standard cygwin). I'd consider that a strong plus for compatibility -- since outside of cygwin, use of the private area will often get you question marks or little square boxes or nothing at all, but this way, visually, at least, they'll look close to how they are intended to look. FWIW, one can use the fullwidth forms of / and \ in pathnames where the OS treats them as normal characters. That's the most important suggestion I have. As a /possible/, further, suggestion (that would take more work, and I don't believe is as important if the above change to use fullwidth characters is made), would be to allow User assignment of what Unicode char to substitute in for the special characters. The chars could be specified by their html id or a pseudo if non exists, so syntax would look like: CYGWIN="[=U+;]" That would allow someone to assign any value they wanted. An advantage of that is that those who still want to access 'ADS', could have "col=U+003A" in their CYGWIN var, and they'd still get that ability. I strongly hope and urge you to use the FULLWIDTH equivalents of the characters you are using. They are shell safe and display properly (I've been using a few of them like the colon and the occasional 'slash',) to properly display song titles in my music library. Linda -- 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: [1.7] git checkout or clean fails to unlink submodule
> On Mon, Nov 23, 2009 at 17:26, Eric Blake wrote: >> According to David Antliff on 11/22/2009 9:20 PM: >>> Any suggestions how to investigate this further? Is there some way >>> that Windows or Cygwin is somehow preventing the deletion of this >>> directory? >> >> More likely, this is due to the fact that git submodule is still an >> interface in progress, and this is likely to be an upstream limitation. >> I'd see if you can reproduce it on Linux, and if so, report it upstream. >> Which reminds me, I need to package a newer version of git soon. I've built git-1.6.4.2 from source on Linux (Ubuntu 8.04.3) and tried the same test case. In this situation I get the following warning: $ git checkout -f master warning: unable to unlink build: Is a directory This seems like a much more sensible warning message than "Operation not permitted" on Cygwin - perhaps there's something that can be improved there? The fact that it doesn't delete the directory is OK with me, and is certainly not a Cygwin issue. However I note that the 'build' directory is still not removed by 'git clean -fdx' so it looks like that is a real-git problem, not a Cygwin-git problem. I tried the same thing with the latest "release" tagged version of git, 1.6.5.3, on Linux and it behaves the same way as 1.6.4.2. So as this thread was really triggered by the ominous "Operation not permitted" warning, I'm not sure there's a Cygwin issue here, except perhaps that warning could be the same as the Linux warning - "Is a directory" - instead? Perhaps this message comes from the Cygwin "OS" in which case it might not be fixable in git. -- David. -- 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: cygserver in cygwin 1.7.0-62 worked, but fails with seg fault in cygwin 1.7.0-63 and -64
cygwin 1.7.0-65 (new setup version) fixes my cygserver problem. Tony -- 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: rsync pull problem and possible solution
over ssh - G. Ralph Kuntz, MD -- View this message in context: http://old.nabble.com/rsync-pull-problem-and-possible-solution-tp26319757p26485641.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync pull problem and possible solution
- Original Message - From: "grkuntzmd" Are you using "push" or "pull"? In other words, are you running rsync on the Windows host and sending to the Linux host, or are you running rsync on the Linux host and retrieving files from the Window machine? It is the latter that hangs. Also are you using it in daemon mode or over ssh, over ssh is dodgy as hell here :( 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: Cannot run SSH
On 11/23/2009 1:32 PM, Alexander Quinn wrote: FWIW, I had the exact same problem. This was under Cygwin 1.5 (not 1.7) and Win7 (build 7600 enterprise release). The OpenSSH server worked for a few days and then stopped working with similar symptoms to you. I eventually got it working again. After working for a couple more days, it broke again. Nevertheless, this is what I did to make it work after not working. I realize some of this may be unnecessary or even counterproductive. I don't know enough Cygwin and/or Windows to say what made a difference so I'm just telling you what I did in the off chance that it helps somebody find the real problem. 1. Stop and delete the service: cygrunsrv --stop sshd cygrunsrv --remove sshd 2. Remove the cyg_server user via Windows. 3. Restart system. 4. From bash, run ssh-host-config to recreate user and sshd service. Answer yes to everything except allow cyg_server to be the name of the user. 5. Manually set the password for the cyg_server user from Cygwin. Make it 10 characters with only alphanumeric (i.e. "abcDEF1234" - not my password obviously). passwd cygserver 6. Go into Services, properties of the sshd service, Log On tab. Manually set that to the stored log on password for the service. 7. Close bash if it's still open. 8. Start-->Run-->"ash" and run the rebaseall command. 9. From the command prompt, run net start sshd. Please forgive the superfluous details. Good luck! Alex Hi Thanks for the help offer, I desperately need it here :) I actually have tried all those steps many times :( including rebasing. But I will try these again in the order of steps you have provided. The only thing I did not try was using alphanumeric password thanks again -- 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: Cannot run SSH
FWIW, I had the exact same problem. This was under Cygwin 1.5 (not 1.7) and Win7 (build 7600 enterprise release). The OpenSSH server worked for a few days and then stopped working with similar symptoms to you. I eventually got it working again. After working for a couple more days, it broke again. Nevertheless, this is what I did to make it work after not working. I realize some of this may be unnecessary or even counterproductive. I don't know enough Cygwin and/or Windows to say what made a difference so I'm just telling you what I did in the off chance that it helps somebody find the real problem. 1. Stop and delete the service: cygrunsrv --stop sshd cygrunsrv --remove sshd 2. Remove the cyg_server user via Windows. 3. Restart system. 4. From bash, run ssh-host-config to recreate user and sshd service. Answer yes to everything except allow cyg_server to be the name of the user. 5. Manually set the password for the cyg_server user from Cygwin. Make it 10 characters with only alphanumeric (i.e. "abcDEF1234" - not my password obviously). passwd cygserver 6. Go into Services, properties of the sshd service, Log On tab. Manually set that to the stored log on password for the service. 7. Close bash if it's still open. 8. Start-->Run-->"ash" and run the rebaseall command. 9. From the command prompt, run net start sshd. Please forgive the superfluous details. Good luck! Alex - Original Message From: baykusderki To: cygwin@cygwin.com Sent: Sun, November 22, 2009 1:29:03 AM Subject: Re: Cannot run SSH On 11/22/2009 12:00 AM, Ken Jackson wrote: > > Is SYSTEM in /etc/passwd? If not, I think that's a problem. Even if > it's there, maybe it's wrong. I would try the mkpasswd command to > recreate your passwd file (and might as well mkgroup to recreate > the /etc/group file). They both write to stdout so you have to > redirect them: > > mkpasswd> /etc/passwd > > -- > 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 > > Yep the SYSTEM is listed alright. I already created the passwd file multiple times, before and after ssh installation. I do not know what all those numbers in it but as far as I can see the users and their default folders listed fine there. I can pretty much see all the defined users including the ssh setup based users. "mkpasswd -cl > /etc/passwd" was the command I have used multiple times. The weird thing was that the Cygwin+Ssh installation on Win7 was the easiest of all installations I had done before. It worked for couple days and stopped yesterday. Something is funky and I cannot figure it out after spending 10 hours on this. I am sure it is couple minutes fix if you are an expert on this stuff but that is the best i can do on my own. -- 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 -- 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: [1.7] Updated: cygwin-1.7.0-65
Jeremy Bopp wrote: Is anyone else receiving another copy of this message every half hour or so? I've received 5 copies so far, all apparently identical. Yes. I only sent the message once, and I only see it once in the archives, so either the list server is sending the extra copies (but why only my message?) or it's my company mail server and the archive is smart enough to suppress the duplicates. I'll do some tests here. -- 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: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On Mon, Nov 23, 2009 at 01:31:58PM +0100, Corinna Vinschen wrote: >On Nov 23 20:04, JonY wrote: >>On 11/23/2009 19:05, Corinna Vinschen wrote: >>>Yes, as well as the -src.tar.bz2 file. That was the sole reason for >>>the missing setup-2.ini entries. >>> >> >>I thought cgf uploaded the packages. Upload went missing? > >It appears so. Aha. I figured out what I did wrong from the shell history. rm *-1.* removed everything in the directory rather than just the -1 version of lzip. Sorry for the confusion. 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: [1.7] Updated: cygwin-1.7.0-65
On Mon, Nov 23, 2009 at 10:07:05PM +0800, Huang Bambo wrote: >2009/11/23 Corinna Vinschen : >> On Nov 23 17:43, Huang Bambo wrote: >>> 2009/11/23 Corinna Vinschen : >>> > On Nov 22 09:33, Huang Bambo wrote: >>> >> And there's another quesiton: >>> >> The handle of chile process( created by fork ) seems never been closed >>> >> bye parent process. Is it need to be closed? >>> > >>> > I don't understand the question. ?There's one dangling socket handle left >>> > and I know where and why it happens. ?Other than that, I don't see any >>> > other socket handling which is left open accidentally. >>> > >>> While run my last test code, every time comes one connection, there >>> are 3 handle leak( I monited it by Process Explorer( from >>> www.sysinternals.com)), one is the chile process's handle, one is of >>> "Section ? ? ?\BaseNamedObjects\cygwin1S5-9770bb4ddbd85dca\cygpid.", >>> the other one is of \Device\Afd. >>> I mean is there any other leak with those handles. >> >> The leak is a result of the parent process not calling wait(2) or >> waitpid(2) to reap the child process. ?If you let the process properly >> call wait/waitpid, you won't see a leak, except for the current socket >> leak this thread is about. > >There's some diffirence between cygwin and other *nix: >In other *nix with this condition, those ended child process could be >list by ps command with tag, will you fix it? Cygwin should produce zombie processes. You don't see zombie processes if the child has exited and the parent goes away though. In that case the process just disappears, just like on linux. You *should* see a zombie when the parent is alive by not waiting for children. The "leak" that Corinna is talking about comes about when the parent has not called wait since the parent keeps handles open to its children until they are reaped. That's how we know whether a process is a zombie or not. 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: grep --color=auto with -i option disables the matching text color
On 2009-11-23, Morten Kjærulff wrote:
> On Mon, Nov 23, 2009 at 4:51 PM, Alan Fay wrote:
> > Howdy!
> >
> > I was trying to enable colors on the matching text for grep, and can't
> > get the formatting to work with the matching text.
> >
> > # Partial contents of .zshenv
> > export GREP_OPTIONS="--color=auto"
> > export GREP_COLORS='mt=1;34'
> >
> > # Problem command, no matching text (mt) appearing bold/blue, run in a
> > C# solution:
> > $ grep -R -n -i -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
> >
> > # Command that works and highlights matching text, note that -i option
> > disabled
> > $ grep -R -n -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
> >
> > My superuser inquiry:
> > http://superuser.com/questions/73261/grep-colorauto-with-i-option-disables-the-matching-text-color-why
> >
> > This problem was found with the following program/platform versions:
> >
> > $ uname -a
> > CYGWIN_NT-6.0-WOW64 *** 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
> >
> > $ grep --version
> > GNU grep 2.5.3
> >
> > $ zsh --version
> > zsh 4.3.9 (i686-pc-cygwin)
> >
> > Windows Vista Business
> > Service Pack 2
> >
> > Feel free to email me with anything that's missing. I'm not sure if
> > this is a bug with Cygwin on Vista or perhaps grep. I didn't find
> > much past the man pages on google with respect to grep colorization
> > (on any platform).
> could be the same as "my" problem:
> http://cygwin.com/ml/cygwin/2009-10/msg00548.html
This appears to be a grep problem and not a Cygwin problem as it
fails for me using grep 2.5.4 on a Red Hat Linux system: Matches
are not colored if the -i option is used and the pattern contains
any upper-case letters.
You might check the grep project page at
http://www.gnu.org/software/grep/. I didn't see it among the
reported bugs. If you don't see it there, either, go ahead and
report it.
Regards,
Gary
--
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: [1.7] Updated: cygwin-1.7.0-65
Warren Young wrote: > Huang Bambo wrote: >>> The leak is a result of the parent process not calling wait(2) or >>> waitpid(2) to reap the child process. >> >> There's some diffirence between cygwin and other *nix: >> In other *nix with this condition, those ended child process could be >> list by ps command with tag > > How much sense does it make to talk about zombies in the Cygwin world? > As soon as the last Cygwin-using process dies, all these resources are > freed up, right? Oppose a standalone POSIX kernel, where orphaned > processes get reparented to init(8), which never dies until reboot, and > the kernel can't be restarted without rebooting the whole machine. On > such a system, zombies are all but unkillable, not like on Cygwin. > > Maybe we need another designation. I suggest "undead skeleton". Easier > to kill, especially if you have a mace enchanted with shock damage. > >> will you fix it? > > PTC, I'm sure. > > -- > 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 > > Is anyone else receiving another copy of this message every half hour or so? I've received 5 copies so far, all apparently identical. -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: grep --color=auto with -i option disables the matching text color
could be the same as "my" problem:
http://cygwin.com/ml/cygwin/2009-10/msg00548.html
www.MortenKjarulff.dk
On Mon, Nov 23, 2009 at 4:51 PM, Alan Fay wrote:
> Howdy!
>
> I was trying to enable colors on the matching text for grep, and can't
> get the formatting to work with the matching text.
>
> # Partial contents of .zshenv
> export GREP_OPTIONS="--color=auto"
> export GREP_COLORS='mt=1;34'
>
> # Problem command, no matching text (mt) appearing bold/blue, run in a
> C# solution:
> $ grep -R -n -i -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
>
> # Command that works and highlights matching text, note that -i option
> disabled
> $ grep -R -n -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
>
> My superuser inquiry:
> http://superuser.com/questions/73261/grep-colorauto-with-i-option-disables-the-matching-text-color-why
>
> This problem was found with the following program/platform versions:
>
> $ uname -a
> CYGWIN_NT-6.0-WOW64 *** 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
>
> $ grep --version
> GNU grep 2.5.3
>
> $ zsh --version
> zsh 4.3.9 (i686-pc-cygwin)
>
> Windows Vista Business
> Service Pack 2
>
> Feel free to email me with anything that's missing. I'm not sure if
> this is a bug with Cygwin on Vista or perhaps grep. I didn't find
> much past the man pages on google with respect to grep colorization
> (on any platform).
>
> Thanks,
> Alan
>
> --
> 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
>
>
--
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
MATHLIB environment variable
Hello,
I have been trying to install the latest Numpy for the Cygwin Python.
However, upon running the following, I get the following
>File "numpy/core/setup.py", line 253, in check_mathlib
> raise EnvironmentError("math library missing; rerun "
>EnvironmentError: math library missing; rerun setup.py after setting the
>MATHLIB env variable
Being quite new to Cygwin, I would appreciate any advice on how to proceed with
setting this.
Thank you for the help,
Olivia
--
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
grep --color=auto with -i option disables the matching text color
Howdy!
I was trying to enable colors on the matching text for grep, and can't
get the formatting to work with the matching text.
# Partial contents of .zshenv
export GREP_OPTIONS="--color=auto"
export GREP_COLORS='mt=1;34'
# Problem command, no matching text (mt) appearing bold/blue, run in a
C# solution:
$ grep -R -n -i -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
# Command that works and highlights matching text, note that -i option disabled
$ grep -R -n -e "functionFoo\(" --include=*.cs --exclude-dir=Logs *
My superuser inquiry:
http://superuser.com/questions/73261/grep-colorauto-with-i-option-disables-the-matching-text-color-why
This problem was found with the following program/platform versions:
$ uname -a
CYGWIN_NT-6.0-WOW64 *** 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
$ grep --version
GNU grep 2.5.3
$ zsh --version
zsh 4.3.9 (i686-pc-cygwin)
Windows Vista Business
Service Pack 2
Feel free to email me with anything that's missing. I'm not sure if
this is a bug with Cygwin on Vista or perhaps grep. I didn't find
much past the man pages on google with respect to grep colorization
(on any platform).
Thanks,
Alan
--
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: [1.7] Updated: cygwin-1.7.0-65
Huang Bambo wrote: The leak is a result of the parent process not calling wait(2) or waitpid(2) to reap the child process. There's some diffirence between cygwin and other *nix: In other *nix with this condition, those ended child process could be list by ps command with tag How much sense does it make to talk about zombies in the Cygwin world? As soon as the last Cygwin-using process dies, all these resources are freed up, right? Oppose a standalone POSIX kernel, where orphaned processes get reparented to init(8), which never dies until reboot, and the kernel can't be restarted without rebooting the whole machine. On such a system, zombies are all but unkillable, not like on Cygwin. Maybe we need another designation. I suggest "undead skeleton". Easier to kill, especially if you have a mace enchanted with shock damage. will you fix it? PTC, I'm sure. -- 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: Where can I find the libresolv in the cygwin
resolved by minires thanks, guys :) 2009/11/23 Nicle > > resolved by minires > > thanks, guys :) > > > > 2009/11/23 Nicle >> >> Hi all, >> >> I am building a xmpp library, named : loudmouth, which is depending the >> libresolv. Unforunately, the libresolv can't be found in cygwin box. >> >> On linking the program with "-lresolv" option, it will return the error >> "can't find -lresolv". >> >> Any help is appreciate! >> >> Best Regards >> Nicle Yang > -- 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: Problem with autoconf autodepend
On 11/22/2009 10:39 PM, Dave Korn wrote: Ken Brown wrote: I guess so. I wonder if there's a timing problem so that the deps directory isn't being created before it needs to be used. But here's something very strange: Angelo Graziosi, who is also playing with this, told me that he *doesn't* get error if he does 'make -j4', but he gets the same error I get with just plain 'make'. I would expect the opposite if it were a timing problem. No, that (potentially) makes perfect sense to me. There's a bug in the makefile; it either has no or wrong dependency for the deps subdir, so it doesn't get created until later in the dependency order than it is first actually needed. If you run at -j4, some of the things later in the dependency order get to happen earlier, including perhaps creating the deps directory, but if you run it in serial dependency order at -j1 the deps dir isn't created in time before it's first used. Can't say for sure whether or not that is what's actually happening, but it's quite plausible. Thanks for the explanations, Dave. I was confused. There was indeed a missing dependency in the makefile, which they have now fixed. Ken -- 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: [1.7] Updated: cygwin-1.7.0-65
2009/11/23 Corinna Vinschen : > On Nov 23 17:43, Huang Bambo wrote: >> 2009/11/23 Corinna Vinschen : >> > On Nov 22 09:33, Huang Bambo wrote: >> >> And there's another quesiton: >> >> The handle of chile process( created by fork ) seems never been closed >> >> bye parent process. Is it need to be closed? >> > >> > I don't understand the question. There's one dangling socket handle left >> > and I know where and why it happens. Other than that, I don't see any >> > other socket handling which is left open accidentally. >> > >> While run my last test code, every time comes one connection, there >> are 3 handle leak( I monited it by Process Explorer( from >> www.sysinternals.com)), one is the chile process's handle, one is of >> "Section \BaseNamedObjects\cygwin1S5-9770bb4ddbd85dca\cygpid.", >> the other one is of \Device\Afd. >> I mean is there any other leak with those handles. > > The leak is a result of the parent process not calling wait(2) or > waitpid(2) to reap the child process. If you let the process properly > call wait/waitpid, you won't see a leak, except for the current socket > leak this thread is about. There's some diffirence between cygwin and other *nix: In other *nix with this condition, those ended child process could be list by ps command with tag, will you fix it? -- 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: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On Nov 23 20:04, JonY wrote: > On 11/23/2009 19:05, Corinna Vinschen wrote: > >Yes, as well as the -src.tar.bz2 file. That was the sole reason for > >the missing setup-2.ini entries. > > > > I thought cgf uploaded the packages. Upload went missing? It appears so. 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: rsync pull problem and possible solution
Are you using "push" or "pull"? In other words, are you running rsync on the Windows host and sending to the Linux host, or are you running rsync on the Linux host and retrieving files from the Window machine? It is the latter that hangs. - G. Ralph Kuntz, MD -- View this message in context: http://old.nabble.com/rsync-pull-problem-and-possible-solution-tp26319757p26477154.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On 11/23/2009 19:05, Corinna Vinschen wrote: On Nov 23 18:28, JonY wrote: On 11/23/2009 17:25, Corinna Vinschen wrote: On Nov 23 07:28, Fergus wrote: but no mention of version: install: source: Which makes sort of sense, given that no lzip tar archive was in the release-2/lzip subdirectory. I fixed that on cygwin.com, so it should be propagated to the mirrors soon. I thought that setup.ini generation was smart enough to figure it out, I'll be sure to have those in the .hint file next time. No! Don't do that, these are autogenerated values which are NOT supposed to be in the setup.hint file. btw, lzip-1.8-2.tar.bz2 was missing? Yes, as well as the -src.tar.bz2 file. That was the sole reason for the missing setup-2.ini entries. I thought cgf uploaded the packages. Upload went missing? -- 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: [1.7] git checkout or clean fails to unlink submodule
On Mon, Nov 23, 2009 at 17:26, Eric Blake wrote: > According to David Antliff on 11/22/2009 9:20 PM: >> Any suggestions how to investigate this further? Is there some way >> that Windows or Cygwin is somehow preventing the deletion of this >> directory? > > More likely, this is due to the fact that git submodule is still an > interface in progress, and this is likely to be an upstream limitation. > I'd see if you can reproduce it on Linux, and if so, report it upstream. > Which reminds me, I need to package a newer version of git soon. Ok, I'll see if I can reproduce in Linux in the next day or two. I would be happy to test (as in, use day to day) a newer version of git on Cygwin if you do package a new one for 1.7 :) -- David. -- 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: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On Nov 23 18:28, JonY wrote: > On 11/23/2009 17:25, Corinna Vinschen wrote: > >On Nov 23 07:28, Fergus wrote: > >>but no mention of > >> > >>version: > >>install: > >>source: > > > >Which makes sort of sense, given that no lzip tar archive was in the > >release-2/lzip subdirectory. I fixed that on cygwin.com, so it should > >be propagated to the mirrors soon. > > I thought that setup.ini generation was smart enough to figure it > out, I'll be sure to have those in the .hint file next time. No! Don't do that, these are autogenerated values which are NOT supposed to be in the setup.hint file. > btw, lzip-1.8-2.tar.bz2 was missing? Yes, as well as the -src.tar.bz2 file. That was the sole reason for the missing setup-2.ini entries. 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: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On 11/23/2009 17:25, Corinna Vinschen wrote: On Nov 23 07:28, Fergus wrote: Sorry, still something not quite right. setup-2.ini timestamp 1258914641 shows @ lzip sdesc: "Lossless data compressor based on the LZMA algorithm." ldesc: "lossless data compressor based on the LZMA algorithm, with very safe integrity checking and a user interface similar to the one of gzip or bzip2." category: Archive requires: cygwin libgcc1 libstdc++6 but no mention of version: install: source: Which makes sort of sense, given that no lzip tar archive was in the release-2/lzip subdirectory. I fixed that on cygwin.com, so it should be propagated to the mirrors soon. Hi, I thought that setup.ini generation was smart enough to figure it out, I'll be sure to have those in the .hint file next time. btw, lzip-1.8-2.tar.bz2 was missing? -- 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: [1.7] Updated: cygwin-1.7.0-65
On Nov 23 17:43, Huang Bambo wrote: > 2009/11/23 Corinna Vinschen : > > On Nov 22 09:33, Huang Bambo wrote: > >> And there's another quesiton: > >> The handle of chile process( created by fork ) seems never been closed > >> bye parent process. Is it need to be closed? > > > > I don't understand the question. There's one dangling socket handle left > > and I know where and why it happens. Other than that, I don't see any > > other socket handling which is left open accidentally. > > > While run my last test code, every time comes one connection, there > are 3 handle leak( I monited it by Process Explorer( from > www.sysinternals.com)), one is the chile process's handle, one is of > "Section \BaseNamedObjects\cygwin1S5-9770bb4ddbd85dca\cygpid.", > the other one is of \Device\Afd. > I mean is there any other leak with those handles. The leak is a result of the parent process not calling wait(2) or waitpid(2) to reap the child process. If you let the process properly call wait/waitpid, you won't see a leak, except for the current socket leak this thread is about. 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: [1.7] Updated: cygwin-1.7.0-65
2009/11/23 Corinna Vinschen :
> On Nov 22 09:33, Huang Bambo wrote:
>> And there's another quesiton:
>> The handle of chile process( created by fork ) seems never been closed
>> bye parent process. Is it need to be closed?
>
> I don't understand the question. There's one dangling socket handle left
> and I know where and why it happens. Other than that, I don't see any
> other socket handling which is left open accidentally.
>
While run my last test code, every time comes one connection, there
are 3 handle leak( I monited it by Process Explorer( from
www.sysinternals.com)), one is the chile process's handle, one is of
"Section\BaseNamedObjects\cygwin1S5-9770bb4ddbd85dca\cygpid.",
the other one is of \Device\Afd.
I mean is there any other leak with those handles.
Simple code like the following will not leak anything:
#include
#include
int main(void)
{
pid_t pid = fork();
while(1)
{
if ( pid == 0 )
{
sleep(5);
printf("Child: %d ended\n", getpid());
return 0;
}
else if ( pid > 0 )
{
printf("New process forked.\n");
sleep(10);
}
}
}
--
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: Interesting problem installing cygserver
On Nov 23 00:34, Gregg Levine wrote: > On Mon, Nov 23, 2009 at 12:06 AM, Larry Hall (Cygwin) > > Not exactly. You aren't running with those privileges. Use "Run as > > Administrator" > > from that account so you get the elevated privileges you need. > > Hello! > That did work. Thank you Larry. I owe you something or other over > coffee and pastry at someplace other then Starbucks the next time your > visiting the City. Or a meal at two of the best delis in the City. > > I freely confess I haven't worked with Cygwin since the Windows98SE > time frame so this capability is a big thing. Just to make this very clear: This isn't a Cygwin problem. You're stumbling over the "User Access Control" (UAC) facility introduced with Windows Vista, see http://msdn.microsoft.com/en-us/library/aa511445.aspx 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: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2
On Nov 23 07:28, Fergus wrote: > Sorry, still something not quite right. > setup-2.ini timestamp 1258914641 > shows > > @ lzip > sdesc: "Lossless data compressor based on the LZMA algorithm." > ldesc: "lossless data compressor based on the LZMA algorithm, with very > safe integrity checking and a user interface similar to the one of > gzip or bzip2." > category: Archive > requires: cygwin libgcc1 libstdc++6 > > but no mention of > > version: > install: > source: Which makes sort of sense, given that no lzip tar archive was in the release-2/lzip subdirectory. I fixed that on cygwin.com, so it should be propagated to the mirrors soon. Thanks for the heads up, 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: [1.7] Updated: cygwin-1.7.0-65
On Nov 22 09:33, Huang Bambo wrote: > And there's another quesiton: > The handle of chile process( created by fork ) seems never been closed > bye parent process. Is it need to be closed? I don't understand the question. There's one dangling socket handle left and I know where and why it happens. Other than that, I don't see any other socket handling which is left open accidentally. 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
