Re: libexecdir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 6/10/2009 10:50 AM: OTOH IMHO this is incorrect: * libexec programs are not meant for direct execution by any user; sbin programs are (by superuser). * libexec is often deep, which AFAIK /usr/sbin should not be per FHS. There are a few other ways of handling libexec: 1) GNU autotools uses /usr/libexec. The problem is that is not FHS-compliant, which we generally try to be. 2) Default to /usr/lib. This will do the right thing when a package wants a subdir of libexecdir (e.g. git, gnupg, octave), but libexec_PROGRAMS will probably want to override that with a subdir thereof. Thoughts? If FHS defines /usr/lib for libexecdir then I have no problems changing this for Cygwin as well. It shouldn't even have any user-visible effect. And for the few packages where it does matter, the packager can provide an override in the .cygport file (just as I am now ending up doing to switch libexecdir to /usr/lib as an override in my git.cygport). I'm in favor of making this change in cygport. - -- 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 iEYEARECAAYFAko2OpYACgkQ84KuGfSFAYAThgCfRyrFADfHLKlhaBZfaXtuS7/l rPMAoIwotHbIOAWjTg+p3k38+YzNT1yj =5MhP -END PGP SIGNATURE-
Re: libexecdir
On Jun 15 06:12, Eric Blake wrote: According to Corinna Vinschen on 6/10/2009 10:50 AM: If FHS defines /usr/lib for libexecdir then I have no problems changing this for Cygwin as well. It shouldn't even have any user-visible effect. And for the few packages where it does matter, the packager can provide an override in the .cygport file (just as I am now ending up doing to switch libexecdir to /usr/lib as an override in my git.cygport). I'm in favor of making this change in cygport. If there's no good reason NOT(*) to switch libexecdir to /usr/lib, I'll change the documentation on http://cygwin.com/setup.html tomorrow. Corinna (*) Aren't double negations lovely? -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: libexecdir
On 15/06/2009 08:50, Corinna Vinschen wrote: If there's no good reason NOT(*) to switch libexecdir to /usr/lib, I'll change the documentation on http://cygwin.com/setup.html tomorrow. Change committed to cygport trunk r6793. Yaakov
RE: XWinrc suggestion
Sounds like a good idea to me. -Chris -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Jack Tanner Sent: Monday, June 08, 2009 1:16 AM To: cygwin-xfree@cygwin.com Subject: XWinrc suggestion It'd be nice if one could specify what are traditionally command-line parameters to XWin.exe in XWinrc. For example, if the functionality were available, I'd use it to turn on emulate3buttons in my .XWinrc. This would be preferable to modifying startxwin.bat, as I do now, because startxwin.bat is wiped out every time Cygwin/X is upgraded. As is conventional, if a parameter occurs in both .XWinrc and on the command line (e.g., in startxwin.bat), the command line parameter value would take precedence. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] New: run2-0.3.0-1
The run2 package provides two utilities: 'run2' and 'checkX' (as the package is actually a renamed and updated successor to the now-obsoleted checkx package). The first utility is a more powerful replacement for the venerable 'run' utility that has long been a part of the cygwin distribution. The second is a test utility that detects whether an Xserver is active, and exits with an appropriate status value. 'run2' launches console programs while hiding any actual console (dos box) that may ordinarily be associated with them. In addition, 'run2' can: * set/modify environment variables before launching the target program * specify a start directory from which to launch the target * detect whether an X server is active or not, and launch one of two different targets -- with different command line arguments, environment settings, and startup dirs. 'run2' uses an external XML configuration file to control its own operation, and to specify the settings which should be applied to the target program(s). [[ compiled using gcc-3.4.4-999 ]] This release supports both cygwin-1.5 and cygwin-1.7. In the future, support for long filenames, wide chars/unicode filenames and xml configfile contents may be added, but only to a cygwin-1.7-specific version (PTC!) CHANGES since (checkx) 0.2.0 o Renamed package to reflect new focus and utility o Added new run2 utility o Almost complete rewrite Known Limitations o Doesn't properly use the new (really) long-filename APIs of cygwin-1.7 o Makes no attempt to handle wide characters, or national language or UTF-8 encodings -- neither in filenames to target applications to launch, nor in the contents of the configuration xml files. Known Regressions (or, stuff that the old run.exe could do, but that run2.exe can't) o Old run.exe could be renamed to, e.g., 'runemacs.exe' and would automatically launch 'emacs.exe' without requiring emacs.exe to appear in the argument list. run2.exe can't do that, and probably never will. o Old run.exe could be compiled with mingw or gcc -mno-cygwin At present, run2 is cygwin-only. Enough major surgery would be required to enable run2 to compile on mingw that I suspect it would be cleaner to create a mingw-run2 branch separate from the main run2 development, rather than clutter the code and build machinery with a bunch of #ifdefs and AM_CONDITIONALS. See the README file for more information. -- Charles Wilson volunteer checkx^H^H^H run2 maintainer for cygwin 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 Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Installation problems
On Mon, 15 Jun 2009, Larry Hall (Cygwin) wrote: On 06/15/2009, Neanderthelle Jones wrote: Looks like it's in 1.7, though you'll have to pull the source to get it. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/bits/?cvsroot=src Thanks. Oh, sorry. Forget about my pointer to PTC. It's clear you feel cheated and just want to moan about how this open-source project has wronged you. In that case, the proper link is: http://cygwin.com/acronyms/#WJM Point taken. I shouldn't have mentioned my time. But if it was impossible to provide the headers on a well-known proprietary operating system, it is not impossible that it might be thought that that was well-known. The remark was hy... Cygwin is not the only open s... -- Elle -- 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: [BUG 1.7 getopt_long() and recv()] has problem for tftp-hpa-5.0 on cygwin-1.7/win2003
as to getopt_long(), this is the suggestion from H. Peter Anvin h...@zytor.com = The Right Thing would be to drop the conflicting functions from their version of libiberty, and just have it naturally fall down to libcygwin. -hpa = -- 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/
[PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
On Jun 14 22:18, IWAMURO Motonori wrote:
2009/6/13 Corinna Vinschen
The problem appears to be that there is no standard for the handling
of ambiguous characters.
Yes, but the guideline exists.
http://cygwin.com/ml/cygwin/2009-05/msg00444.html
A single mail in a single mailing list of a single project. That's rather
a suggestion than a guideline...
Ambiguous characters behave like wide or narrow characters depending
on the context (language tag, script identification, associated
font, source of data, or explicit markup; all can provide the
context). If the context cannot be established reliably, they should
be treated as narrow characters by default.
Define the default for ja, ko, and zh to use width = 2, with a
@cjknarrow (or whatever) modifier to use width = 1.
I think it is good idea.
If everybody agrees to this suggestion, here's the patch. Tested
with various combinations like
lang=ja_jp.ut...@cjknarrow
lang=ja...@cjknarrow
lang=ja.ut...@cjknarrow
lang...@cjknarrow
Corinna
* libc/locale/locale.c (loadlocale): Add handling of @cjknarrow
modifier on _MB_CAPABLE targets. Add comment to explain.
Index: libc/locale/locale.c
===
RCS file: /cvs/src/src/newlib/libc/locale/locale.c,v
retrieving revision 1.20
diff -u -p -r1.20 locale.c
--- libc/locale/locale.c3 Jun 2009 19:28:22 - 1.20
+++ libc/locale/locale.c15 Jun 2009 08:40:46 -
@@ -397,6 +397,9 @@ loadlocale(struct _reent *p, int categor
int (*l_wctomb) (struct _reent *, char *, wchar_t, const char *, mbstate_t
*);
int (*l_mbtowc) (struct _reent *, wchar_t *, const char *, size_t,
const char *, mbstate_t *);
+#ifdef _MB_CAPABLE
+ int cjknarrow = 0;
+#endif
/* POSIX is translated to C, as on Linux. */
if (!strcmp (locale, POSIX))
@@ -427,10 +430,14 @@ loadlocale(struct _reent *p, int categor
if (c[0] == '.')
{
/* Charset */
- strcpy (charset, c + 1);
- if ((c = strchr (charset, '@')))
+ char *chp;
+
+ ++c;
+ strcpy (charset, c);
+ if ((chp = strchr (charset, '@')))
/* Strip off modifier */
- *c = '\0';
+ *chp = '\0';
+ c += strlen (charset);
}
else if (c[0] == '\0' || c[0] == '@')
/* End of string or just a modifier */
@@ -442,6 +449,17 @@ loadlocale(struct _reent *p, int categor
else
/* Invalid string */
return NULL;
+#ifdef _MB_CAPABLE
+ if (c[0] == '@')
+ {
+ /* Modifier */
+ /* Only one modifier is recognized right now. cjknarrow is used
+to modify the behaviour of wcwidth() for East Asian languages.
+For details see the comment at the end of this function. */
+ if (!strcmp (c + 1, cjknarrow))
+ cjknarrow = 1;
+ }
+#endif
}
/* We only support this subset of charsets. */
switch (charset[0])
@@ -604,13 +622,15 @@ loadlocale(struct _reent *p, int categor
__mbtowc = l_mbtowc;
__set_ctype (charset);
/* Check for the language part of the locale specifier. In case
- of ja, ko, or zh, assume the use of CJK fonts. This is
-stored in lc_ctype_cjk_lang and tested in wcwidth() to figure
-out the width to return (1 or 2) for the CJK Ambiguous Width
-category of characters. */
- lc_ctype_cjk_lang = (strncmp (locale, ja, 2) == 0
- || strncmp (locale, ko, 2) == 0
- || strncmp (locale, zh, 2) == 0);
+ of ja, ko, or zh, assume the use of CJK fonts, unless the
+@cjknarrow modifier has been specifed.
+The result is stored in lc_ctype_cjk_lang and tested in wcwidth()
+to figure out the width to return (1 or 2) for the CJK Ambiguous
+Width category of characters. */
+ lc_ctype_cjk_lang = !cjknarrow
+ ((strncmp (locale, ja, 2) == 0
+ || strncmp (locale, ko, 2) == 0
+ || strncmp (locale, zh, 2) == 0));
#endif
}
else if (category == LC_MESSAGES)
--
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: LFTP issue
On Jun 14 20:30, Chris Sutcliffe wrote: The latest snapshot should eliminate the duplicate results. Works like a charm. Thank you for fixing this! Same here. The weird hangs disappeared as well. 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: ioctl(sock, SIOCGIFHWADDR, ifr) fails with 1.7
To fix your application, call either
struct ifconf ifc;
ifc.ifc_len = sizeof (struct ifreq) * 32;
ifc.ifc_buf = malloc (ifc.ifc_len);
if (ioctl (fd, SIOCGIFCONF, ifc))
/* Resize ifc_buf and retry */
else
{
struct ifreq *ifr = ifc.ifc_req;
struct ifreq ifr2;
for (int i = 0; i ifc.ifc_len; i += sizeof (struct ifreq), ++ifr)
if (!ioctl (fd, SIOCGIFADDR, ifr2))
/* Print result for that interface */
}
Thanks, this works half! No need of ifr2, ifr is enough.
I saw the name change: 1.5 gives eth0, eth1, eth2, lo and 1.7 gives
{821C54BE-...}...
However, with that code, I get all network adapters with cygwin 1.5
but only active adpaters with 1.7 (with IP adress != 0).
For example if I unplug the ethernet wire, the ip of eth0 becomes
0.0.0.0 with 1.5 and I don't see it anymore with 1.7.
How can I get all interfaces with 1.7?
Frédéric
--
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: ioctl(sock, SIOCGIFHWADDR, ifr) fails with 1.7
On Jun 15 11:22, Fr?d?ric Bron wrote:
To fix your application, call either
struct ifconf ifc;
ifc.ifc_len = sizeof (struct ifreq) * 32;
ifc.ifc_buf = malloc (ifc.ifc_len);
if (ioctl (fd, SIOCGIFCONF, ifc))
/* Resize ifc_buf and retry */
else
{
struct ifreq *ifr = ifc.ifc_req;
struct ifreq ifr2;
for (int i = 0; i ifc.ifc_len; i += sizeof (struct ifreq), ++ifr)
if (!ioctl (fd, SIOCGIFADDR, ifr2))
/* Print result for that interface */
}
Thanks, this works half! No need of ifr2, ifr is enough.
I saw the name change: 1.5 gives eth0, eth1, eth2, lo and 1.7 gives
{821C54BE-...}...
However, with that code, I get all network adapters with cygwin 1.5
but only active adpaters with 1.7 (with IP adress != 0).
For example if I unplug the ethernet wire, the ip of eth0 becomes
0.0.0.0 with 1.5 and I don't see it anymore with 1.7.
How can I get all interfaces with 1.7?
I just debugged this and the answer is, right now you can't. I'm
going to fix that at one point, but I have other stuff to do first.
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: [BUG 1.7 getopt_long() and recv()] has problem for tftp-hpa-5.0 on cygwin-1.7/win2003
All resolved now! * getopt_long(): H. Peter Anvin h...@zytor.com has provided Corrected patch (the first one won't work). and the getopt_log links to cygwin now and works well. * recv(): the new snapshot has fixed the bug, and works fine. now the tftp-hap-5.0 work well. thank you all very much! -hpa -Inline Attachment Follows- diff --git a/configure.in b/configure.in index ca21af7..ad00696 100644 --- a/configure.in +++ b/configure.in @@ -154,7 +154,7 @@ XTRA=false PA_SEARCH_LIBS_AND_ADD(xmalloc, iberty) PA_SEARCH_LIBS_AND_ADD(xstrdup, iberty) PA_SEARCH_LIBS_AND_ADD(bsd_signal, bsd, bsdsignal) -PA_SEARCH_LIBS_AND_ADD(getopt_long, getopt, getopt_long) +PA_SEARCH_LIBS_AND_ADD(getopt_long, [getopt cygwin iberty], getopt_long) PA_SEARCH_LIBS_AND_ADD(getaddrinfo, [nsl resolv]) if $pa_add_getaddrinfo then @@ -184,6 +184,11 @@ then XTRALIBS=$OBJROOT/lib/libxtra.a $XTRALIBS fi +dnl Workaround for Cygwin: the version of getopt_long in libiberty causes +dnl problems; we want the one in libcygwin, so if libcygwin exists, +dnl we want to link to it +AC_CHECK_LIB(cygwin, getopt_long) + dnl dnl These libraries apply to the server only dnl -- 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: Garbage man pages
Dave Korn wrote: Haojun Bao wrote: Bill McCormick wrote: Bill McCormick wrote: Bill McCormick wrote: Hello, There's something wrong with my man pager; it's producing garbage output. My ~/.bashrc has these entries: export MANPAGER='less -isrR' export PAGER='less -r' Hi, I also have the same issue. however, there was a warning before I do `man find' that says: Warning: cannot open configuration file /usr/share/misc/man.conf So, after a `find /etc -name man.conf', I fixed it by this command: cp /etc/defaults/usr/share/misc/man.conf /usr/share/misc/man.conf This maybe a packaging problem? I tried temporarily moving my man.conf out of the way and it also reproduces the symptom's of Bill's problem exactly as he describes. Bill, try this! Yep. That's it. Thanks, Bill -- 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
2009/6/15 Corinna Vinschen corinna-cyg...@cygwin.com:
Yes, but the guideline exists.
http://cygwin.com/ml/cygwin/2009-05/msg00444.html
A single mail in a single mailing list of a single project. That's rather
a suggestion than a guideline...
Sorry, my writing was bad. My quotation is a part of Unicode Standard
Annex #11 EAST ASIAN WIDTH.
Please see When processing or displaying data of 5 Recommendations
at http://www.unicode.org/unicode/reports/tr11/ .
If everybody agrees to this suggestion, here's the patch.
Is the name of modifier prefix cjk- good? It influences not CJK
characters but a part of symbols and European characters.
Please refer to Andy's opinion:
http://cygwin.com/ml/cygwin/2009-06/msg00240.html
It personally proposes ambinarrow because the switch of Vim is ambiwidth.
And, I don't think that it is symmetrical. How about the following
patch? (I have not changed the name of modifier prefix)
--- libc/locale/locale.c.ORIG 2009-06-15 23:05:40.81250 +0900
+++ libc/locale/locale.c2009-06-15 22:56:35.546875000 +0900
@@ -398,7 +398,8 @@
int (*l_mbtowc) (struct _reent *, wchar_t *, const char *, size_t,
const char *, mbstate_t *);
#ifdef _MB_CAPABLE
- int cjknarrow = 0;
+#define CJK_DEFAULT -1
+ int cjk_lang = CJK_DEFAULT;
#endif
/* POSIX is translated to C, as on Linux. */
@@ -453,11 +454,14 @@
if (c[0] == '@')
{
/* Modifier */
- /* Only one modifier is recognized right now. cjknarrow is used
-to modify the behaviour of wcwidth() for East Asian languages.
-For details see the comment at the end of this function. */
+ /* Only one modifier is recognized right now. cjknarrow and
+cjkwide are used to modify the behaviour of wcwidth() for
+East Asian languages. For details see the comment at the
+end of this function. */
if (!strcmp (c + 1, cjknarrow))
- cjknarrow = 1;
+ cjk_lang = 0;
+ else if (!strcmp (c + 1, cjkwide))
+ cjk_lang = 1;
}
#endif
}
@@ -627,10 +631,11 @@
The result is stored in lc_ctype_cjk_lang and tested in wcwidth()
to figure out the width to return (1 or 2) for the CJK Ambiguous
Width category of characters. */
- lc_ctype_cjk_lang = !cjknarrow
- ((strncmp (locale, ja, 2) == 0
-|| strncmp (locale, ko, 2) == 0
-|| strncmp (locale, zh, 2) == 0));
+ lc_ctype_cjk_lang = cjk_lang != CJK_DEFAULT
+ ? cjk_lang
+ : ((strncmp (locale, ja, 2) == 0
+ || strncmp (locale, ko, 2) == 0
+ || strncmp (locale, zh, 2) == 0));
#endif
}
else if (category == LC_MESSAGES)
--
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/
Optimize cygwin on recent windows version (Vista and Seven)
Hi, Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. Now when I test cygwin, everything is so sloowww, I know this is not something new but do you plan to work on this issue ? From what I know, the problem comes from fork implementation but actually as a user I don't care where does it come from I am only noticing I cannot work anymore with cygwin. Have you ever thought of something to improve things ? Will it be one day possible ? Are you lacking some information from MS ? It's so annoying that with very modern hardware I feel like runnning a windows 3.1 on a 128 KB system ... If you answer that it's not possible to do better, in this case I will to find alternatives. Don't know if mingw could be one of them ? -- 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
On Jun 15 23:35, IWAMURO Motonori wrote: 2009/6/15 Corinna Vinschen: If everybody agrees to this suggestion, here's the patch. Is the name of modifier prefix cjk- good? It influences not CJK characters but a part of symbols and European characters. Please refer to Andy's opinion: http://cygwin.com/ml/cygwin/2009-06/msg00240.html It personally proposes ambinarrow because the switch of Vim is ambiwidth. I think cjk in the name is the right choice. There are no ambiguous characters in western languages (well, probably there are, but the ambiguity is not on the level of character widths). This is a problem which only has a meaning in these so called CJK languages. It makes sense to me to use this in the modifier name. And, I don't think that it is symmetrical. How about the following patch? (I have not changed the name of modifier prefix) I'm not convinced that we need symmetry. It looks like a nice idea for Cygwin or newlib, given that the setlocale language string is checked and picked to pieces hardcoded in the loadlocale function. However, besides of being unnecessary, other systems like Linux or BSD use the language string as directory name relative to the /usr/share/locale directory. If this gets ever used on non-Cygwin systems, the symmetry (which has no precedent in the locale arena) would require these systems to create yet another subdirectory or symlink for the same purpose. Even worse, if you propose that @cjkwide is a valid modifier for *any* language, you would make the whole mechanism on non-newlib based systems more complicated for no apparent reason. 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
OK. I withdraw my proposal. 2009/6/16 Corinna Vinschen corinna-cyg...@cygwin.com: On Jun 15 23:35, IWAMURO Motonori wrote: 2009/6/15 Corinna Vinschen: If everybody agrees to this suggestion, here's the patch. Is the name of modifier prefix cjk- good? It influences not CJK characters but a part of symbols and European characters. Please refer to Andy's opinion: http://cygwin.com/ml/cygwin/2009-06/msg00240.html It personally proposes ambinarrow because the switch of Vim is ambiwidth. I think cjk in the name is the right choice. There are no ambiguous characters in western languages (well, probably there are, but the ambiguity is not on the level of character widths). This is a problem which only has a meaning in these so called CJK languages. It makes sense to me to use this in the modifier name. And, I don't think that it is symmetrical. How about the following patch? (I have not changed the name of modifier prefix) I'm not convinced that we need symmetry. It looks like a nice idea for Cygwin or newlib, given that the setlocale language string is checked and picked to pieces hardcoded in the loadlocale function. However, besides of being unnecessary, other systems like Linux or BSD use the language string as directory name relative to the /usr/share/locale directory. If this gets ever used on non-Cygwin systems, the symmetry (which has no precedent in the locale arena) would require these systems to create yet another subdirectory or symlink for the same purpose. Even worse, if you propose that @cjkwide is a valid modifier for *any* language, you would make the whole mechanism on non-newlib based systems more complicated for no apparent reason. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
how big is a complete cygwin?
How big (approximately) is a complete current Cygwin installation ? Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: how big is a complete cygwin?
From: Damián Rodríguez Sánchez How big (approximately) is a complete current Cygwin installation ? The FAQ is your friend. http://cygwin.com/faq/faq-nochunks.html#faq.setup.disk-space -- 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: [ANNOUNCEMENT] New: run2-0.3.0-1
Perhaps there is a problem on the mirrors: run2 is in the repository but setup.ini is dated 20090609, and it does not contain references to run2. Cheers, Angelo. -- 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 big is a complete cygwin?
probably larger than 800MB installed doesn't help much, when was that written? 1995? I have an old version of Cygwin (over 3 years old, no updates) on my computer that takes almost 3GB of disk space. I wanted to make a full new download of Cygwin for another computer, so I was wondering if anybody had the updated information. Buchbinder, Barry (NIH/NIAID) [E] escreveu: From: Damián Rodríguez Sánchez How big (approximately) is a complete current Cygwin installation ? The FAQ is your friend. http://cygwin.com/faq/faq-nochunks.html#faq.setup.disk-space -- 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: Optimize cygwin on recent windows version (Vista and Seven)
Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. Now when I test cygwin, everything is so sloowww Not exactly a helpful problem report. In what sort of scenarios do you find it to be slow? Is it actually slower than your old system? One issue that I've noticed on Windows 7, both with Cygwin 1.5 and 1.7, is that trying to log a utmp entry when starting a terminal can take up to half a minute, presumably due to waiting for some sort of timeout. Andy -- 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: Optimize cygwin on recent windows version (Vista and Seven)
On Mon, Jun 15, 2009 at 07:39:39PM +0100, Andy Koppe wrote: Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. Now when I test cygwin, everything is so sloowww Not exactly a helpful problem report. In what sort of scenarios do you find it to be slow? Is it actually slower than your old system? One issue that I've noticed on Windows 7, both with Cygwin 1.5 and 1.7, is that trying to log a utmp entry when starting a terminal can take up to half a minute, presumably due to waiting for some sort of timeout. Sorry but this isn't a much more useful report. Do you have code which demonstrates the timeout? 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: Optimize cygwin on recent windows version (Vista and Seven)
2009/6/15 Christopher Faylor:
One issue that I've noticed on Windows 7, both with Cygwin 1.5 and
1.7, is that trying to log a utmp entry when starting a terminal can
take up to half a minute, presumably due to waiting for some sort of
timeout.
Sorry but this isn't a much more useful report.
You're right, sorry. Here's how I got it: repeatedly invoke rxvt,
xterm, or 'mintty -u'. The first invocation would usually be fine, but
subsequent invocations would hang for something like half a minute.
When disabling the utmp entry, using 'rxvt -ut', 'xterm -ut', or
mintty without -u, there'd be no delay.
In MinTTY, the -u option activates the following bit of code. fd is
the master side of its pseudo terminal:
static struct utmp ut;
...
ut.ut_type = USER_PROCESS;
ut.ut_pid = pid;
ut.ut_time = time(0);
char *dev = ptsname(fd);
if (dev) {
if (strncmp(dev, /dev/, 5) == 0)
dev += 5;
strncpy(ut.ut_line, dev ?: ?, sizeof ut.ut_line);
if (strncmp(dev, pty, 3) == 0 || strncmp(dev, tty, 3) == 0)
dev += 3;
strncpy(ut.ut_id, dev ?: ?, sizeof ut.ut_id);
}
strncpy(ut.ut_user, (pw ? pw-pw_name : 0) ?: ?, sizeof ut.ut_user);
login(ut);
Unfortunately my Windows 7 machine went belly-up, so I can't look into
this further at the moment.
Andy
--
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: ioctl(sock, SIOCGIFHWADDR, ifr) fails with 1.7
On Jun 15 13:42, Corinna Vinschen wrote:
On Jun 15 11:22, Fr?d?ric Bron wrote:
To fix your application, call either
struct ifconf ifc;
ifc.ifc_len = sizeof (struct ifreq) * 32;
ifc.ifc_buf = malloc (ifc.ifc_len);
if (ioctl (fd, SIOCGIFCONF, ifc))
/* Resize ifc_buf and retry */
else
{
struct ifreq *ifr = ifc.ifc_req;
struct ifreq ifr2;
for (int i = 0; i ifc.ifc_len; i += sizeof (struct ifreq), ++ifr)
if (!ioctl (fd, SIOCGIFADDR, ifr2))
/* Print result for that interface */
}
Thanks, this works half! No need of ifr2, ifr is enough.
I saw the name change: 1.5 gives eth0, eth1, eth2, lo and 1.7 gives
{821C54BE-...}...
However, with that code, I get all network adapters with cygwin 1.5
but only active adpaters with 1.7 (with IP adress != 0).
For example if I unplug the ethernet wire, the ip of eth0 becomes
0.0.0.0 with 1.5 and I don't see it anymore with 1.7.
How can I get all interfaces with 1.7?
I just debugged this and the answer is, right now you can't. I'm
going to fix that at one point, but I have other stuff to do first.
I applied a patch to Cygwin which also reports the IPv4 addresses of
disconnected interfaces, fetching the info from the registry. It's
a pity that Windows doesn't correctly report these addresses in the
official API.
This won't work for IPv6 and IPv6-only interfaces. I didn't find a
generic way to list IPv6 addresses except for using the official API.
Since Windows Vista the IPv6 address information isn't stored in the
registry at all, at least not in a publically available, easy to read
place.
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: Optimize cygwin on recent windows version (Vista and Seven)
On Mon, 15 Jun 2009 19:39:39 +0100, Andy Koppe andy.ko...@gmail.com wrote: Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. Now when I test cygwin, everything is so sloowww Not exactly a helpful problem report. In what sort of scenarios do you find it to be slow? Is it actually slower than your old system? Easy just try to rebuild a true software( for instance gcc) and you will have one year more between the moment you start the build and the moment it's over. I am not kidding, if you just play with cygwin of course you cannot notice the problem. If you like I could make some benchmark... -- 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: Optimize cygwin on recent windows version (Vista and Seven)
- Original Message - From: Vincent R. foru...@smartmobili.com To: cygwin@cygwin.com Sent: Tuesday, June 16, 2009 1:03 AM Subject: Optimize cygwin on recent windows version (Vista and Seven) Hi, Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. I don't have Windows Seven - but I do have Windows Vista, which seems to be afflicted with the same crippling disabilities as Windows Seven, afaict. Now when I test cygwin, everything is so sloowww, I know this is not something new but do you plan to work on this issue ? Don't know if mingw could be one of them ? I regularly build libraries using MinGW in the MSYS shell (by running './configure', 'make', etc.). I find this activity is a little quicker with MinGW/MSYS than with Cygwin. However, the main problem seems to be the OS - and your best way of getting a reasonable performance for this type of activity is to stick with XP. (Maybe Win2K and earlier offer even better performance - I haven't checked.) Here are some timings I did recently for building the mpc-0.6 library. On Vista and XP, (in the same version of the MSYS shell, and using the same version of MinGW's gcc) I ran: ./configure --disable-shared --enable-static CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make make check On linux (mdk-9.1) and cygwin, it was the same command, but without the CPPFLAGS and LDFLAGS arguments (as they're not necessary on linux and cygwin). Times taken were: Linux : 1.5 mimutes XP (mingw): 6.5 minutes Vista (mingw): 16.5 minutes Vista (cygwin): 23.25 minutes In terms of processor capacity, the Vista box should be the fastest, followed by the XP box, followed by the old Linux box, but clearly, OS considerations are well and truly overwhelming those capacities. (If it were just up to the processor speeds, then there wouldn't be a great difference, anyway.) I raised this on the MinGW list, and the feeling there was that there wasn't much that the MinGW folk could do about it. (I didn't present the cygwin timings to the MinGW list, as I've only just done them now.) One suggestion was to build the libraries on the linux box as a cross-compilation. Even for a small library like mpc it might be worth doing that way (assuming you have access to a linux box), and for something like gmp, which takes over an hour to build and test on Vista, it's definitely an appealing idea. I don't have Cygwin on the XP laptop - but I assume it would perform the task more than twice as quickly on XP (as did MinGW/MSYS). 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: [ANNOUNCEMENT] New: run2-0.3.0-1
Angelo Graziosi wrote: Perhaps there is a problem on the mirrors: run2 is in the repository but setup.ini is dated 20090609, and it does not contain references to run2. Confirmed. This is actually a sourceware problem, not a mirror problem. The last time setup.ini (or setup-2.ini) was updated was almost a week ago. Chris, any idea what's going on? -- Chuck -- 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: Optimize cygwin on recent windows version (Vista and Seven)
I guess it is because of some security specialty, check your settings. 2009/6/15 Vincent R. foru...@smartmobili.com: Hi, Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. Now when I test cygwin, everything is so sloowww, I know this is not something new but do you plan to work on this issue ? From what I know, the problem comes from fork implementation but actually as a user I don't care where does it come from I am only noticing I cannot work anymore with cygwin. Have you ever thought of something to improve things ? Will it be one day possible ? Are you lacking some information from MS ? It's so annoying that with very modern hardware I feel like runnning a windows 3.1 on a 128 KB system ... If you answer that it's not possible to do better, in this case I will to find alternatives. Don't know if mingw could be one of them ? -- 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/
libtool: bug in AC_PROG_LD
Chuck, There's a bug in LT_PATH_LD (AC_PROG_LD) when called prior to LT_INIT (AC_PROG_LIBTOOL): checking for ld used by gcc... /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: no input files ./configure: line 3955: : command not found Yet this does not occur when the same macro is run by LT_INIT. Here's the offending hunk: # Canonicalize the pathname of ld ac_prog=`$ECHO $ac_prog| $SED 's%%/%g'` while $ECHO $ac_prog | $GREP $re_direlt /dev/null 21; do ac_prog=`$ECHO $ac_prog| $SED s%$re_direlt%/%` done The problem is that $ECHO hasn't been defined yet. This is done by _LT_PROG_ECHO_BACKSLASH, which is called at the beginning of LT_INIT, but isn't an explicit requirement of LT_PATH_LD, which may be called on its own. (AFAICS, all other macros which use $ECHO are libtool-internal and would only be called after LT_INIT.) Patch attached. Yaakov * libltdl/m4/libtool.m4 (LT_PATH_LD): Require _LT_PROG_ECHO_BACKSLASH to define $ECHO in case it is called before LT_INIT. --- libltdl/m4/libtool.m4 |1 + 1 file changed, 1 insertion(+), 0 deletions(-) --- libltdl/m4/libtool.m4 2009-06-11 00:03:10.0 -0500 +++ libltdl/m4/libtool.m4 2009-06-15 20:10:31.227624900 -0500 @@ -2772,6 +2772,7 @@ AC_REQUIRE([AC_CANONICAL_HOST])dnl AC_REQUIRE([AC_CANONICAL_BUILD])dnl m4_require([_LT_DECL_SED])dnl m4_require([_LT_DECL_EGREP])dnl +m4_require([_LT_PROG_ECHO_BACKSLASH])dnl AC_ARG_WITH([gnu-ld], [AS_HELP_STRING([--with-gnu-ld], -- 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: Optimize cygwin on recent windows version (Vista and Seven)
On Mon, June 15, 2009 19:53, Sisyphus wrote: Here are some timings I did recently for building the mpc-0.6 library. On Vista and XP, (in the same version of the MSYS shell, and using the same version of MinGW's gcc) I ran: ./configure --disable-shared --enable-static CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib make make check On linux (mdk-9.1) and cygwin, it was the same command, but without the CPPFLAGS and LDFLAGS arguments (as they're not necessary on linux and cygwin). Times taken were: Linux : 1.5 mimutes XP (mingw): 6.5 minutes Vista (mingw): 16.5 minutes Vista (cygwin): 23.25 minutes In terms of processor capacity, the Vista box should be the fastest, followed by the XP box, followed by the old Linux box, but clearly, OS considerations are well and truly overwhelming those capacities. Are these tests on 64-bit or 32-bit Windows? See this post for example, http://sourceware.org/ml/cygwin/2008-09/msg00405.html I have personally noticed a great speed difference where a slower processor 32-bit Windows XP machine outperformed a faster processor 64-bit Windows XP machines during just a make clean. I tried (and failed) to look for anything different on the machines that would account for the vast speed disparity. Both were up to date on their security patches and service packs. I ran cygcheck to make sure the packages used were the same on both machines. I looked at the task manager to ensure there were no other processes running on the slower 64-bit machine that could also be using the computer. Neither of them had antivirus software. Note also that this is both on Windows XP so it's not anything related to Vista at all. Nothing. Cygwin is just way slower on 64-bit Windows. For another performance related thread illustrating the speed difference between forking (and not): http://sourceware.org/ml/cygwin/2009-04/msg00718.html Once we're into forking, see this old performance complaint: http://sourceware.org/ml/cygwin/2006-09/msg00023.html Note the times at the bottom of the post. There's a significant speed difference between snapshot 20060309 and 20060318 (using binary mounts). I used to use Cygwin B20.1 in the day and it has always seemed faster to me. Mind you, it also crashed more though. :) Regards, -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/
New: run2-0.3.0-1
The run2 package provides two utilities: 'run2' and 'checkX' (as the package is actually a renamed and updated successor to the now-obsoleted checkx package). The first utility is a more powerful replacement for the venerable 'run' utility that has long been a part of the cygwin distribution. The second is a test utility that detects whether an Xserver is active, and exits with an appropriate status value. 'run2' launches console programs while hiding any actual console (dos box) that may ordinarily be associated with them. In addition, 'run2' can: * set/modify environment variables before launching the target program * specify a start directory from which to launch the target * detect whether an X server is active or not, and launch one of two different targets -- with different command line arguments, environment settings, and startup dirs. 'run2' uses an external XML configuration file to control its own operation, and to specify the settings which should be applied to the target program(s). [[ compiled using gcc-3.4.4-999 ]] This release supports both cygwin-1.5 and cygwin-1.7. In the future, support for long filenames, wide chars/unicode filenames and xml configfile contents may be added, but only to a cygwin-1.7-specific version (PTC!) CHANGES since (checkx) 0.2.0 o Renamed package to reflect new focus and utility o Added new run2 utility o Almost complete rewrite Known Limitations o Doesn't properly use the new (really) long-filename APIs of cygwin-1.7 o Makes no attempt to handle wide characters, or national language or UTF-8 encodings -- neither in filenames to target applications to launch, nor in the contents of the configuration xml files. Known Regressions (or, stuff that the old run.exe could do, but that run2.exe can't) o Old run.exe could be renamed to, e.g., 'runemacs.exe' and would automatically launch 'emacs.exe' without requiring emacs.exe to appear in the argument list. run2.exe can't do that, and probably never will. o Old run.exe could be compiled with mingw or gcc -mno-cygwin At present, run2 is cygwin-only. Enough major surgery would be required to enable run2 to compile on mingw that I suspect it would be cleaner to create a mingw-run2 branch separate from the main run2 development, rather than clutter the code and build machinery with a bunch of #ifdefs and AM_CONDITIONALS. See the README file for more information. -- Charles Wilson volunteer checkx^H^H^H run2 maintainer for cygwin 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 Please read *all* of the information on unsubscribing that is available starting at this URL.
