R: [ITP] talkfilters-3.8.1-1
--- Sab 7/11/09, JonY ha scritto: Hi, This utility transforms English text into stereotyped dialects. The files are under http://www.cadforte.com/cygwin-uploader/. Unfortunately, its not browsable, here is the file list. Hi Jon to make it brownsable, you need to add a index.html file in all the directories. If you make so, than you can just suggest to download with : $ wget -r -np -nH --cut-dirs=2 http://www.cadforte.com/cygwin-uploader/talkfilters/ Eventually to build all the index.html you can reuse the script I am using (put them in your $HOME/bin ) and run dir2html.sh in the main to create all the index.html in the main and in the sub directories. To download them $ wget -r -np -nH --cut-dirs=1 http://matzeri.altervista.org/script/ To create the file list for the mail, you can use a command like: $ find -type f |grep -v index |colrm 1 2 \---talkfilters | setup.hint | talkfilters-2.3.8-1-src.tar.bz2 | talkfilters-2.3.8-1.tar.bz2 | +---libtalkfilters1 | libtalkfilters1-2.3.8-1.tar.bz2 | setup.hint | \---talkfilters-devel setup.hint talkfilters-devel-2.3.8-1.tar.bz2 Example: http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-2.3.8-1-src.tar.bz2 homepage: http://www.hyperrealm.com/main.php?s=talkfilters category: Text requires: cygwin libgcc1 sdesc: Mimics a stereotyped or otherwise humorous dialect. ldesc: Mimics a stereotyped or otherwise humorous dialect. These filters have been in the public domain for many years, but now for the first time they are provided as a single integrated package. The frontend executables do not depend on the libtalkfilters dll at runtime. Comments? Regards Marco
Re: [RFU 1.7] mpclib-0.8-1
On Nov 9 12:45, David Billinghurst wrote: mpclib-0.8-1 for cygwin-1.7 is available for upload. This is a new upstream release. It now supports all C99 math functions and will be required for gcc-4.5. As with mpclib-0.7, I have chosen not to bump the DLL version number, as the DLL is backwards compatible. AFAICT mpclib is only used to build CVS gcc (4.5). Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [1.7] ITP: libassuan
On Nov 6 15:35, Charles Wilson wrote: Charles Wilson wrote: libassuan is included in debian stable and testing: http://packages.debian.org/search?keywords=libassuan and Fedora 11 https://admin.fedoraproject.org/pkgdb/packages/name/libassuan?#Fedora11 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-1.0.5-1-src.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-1.0.5-1.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-devel/libassuan-devel-1.0.5-1.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-devel/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/setup.hint == libassuan-devel setup.hint = requires: libpth-devel category: Devel Libs external-source: libassuan sdesc: IPC library used by GnuPG2 (devel) ldesc: Libassuan is the IPC library used by GnuPG2, GPGME and a few other packages. == libassuan setup.hint = requires: libassuan-devel category: Doc sdesc: IPC library used by GnuPG2 ldesc: Libassuan is the IPC library used by GnuPG2, GPGME and a few other packages. OK? Ping? Packaging looks ok, but is it really necessary to have a libassuan package which only provides the documentation which you then need if you install libassuan-devel? I think it would be simpler to haave only a libassuan-devel package. Otherwise I'm wondering if the requirements aren't upside down. You require libassuan (the docs) if you install libassuan-devel, but not vice versa... Anyway, it's ok to upload as you prefer. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [1.7] ITP: pinentry
On Nov 6 15:33, Charles Wilson wrote: Charles Wilson wrote: Yaakov (Cygwin/X) wrote: Please do not make a gtk1 version. As for Qt, 3.x is now obsolete, but there are still a (diminishing) number of programs yet to be ported. OK. Revised: http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-0.7.6-2-src.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-gtk2/pinentry-gtk2-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-gtk2/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-qt3/pinentry-qt3-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-qt3/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/setup.hint = pinentry-qt setup.hint === requires: pinentry alternatives libqt3 libncurses9 libiconv2 libgcc1 libstdc++6 category: Utils Gnome external-source: pinentry sdesc: PIN Entry (qt3) ldesc: This is a collection of simple PIN or passphrase entry dialogs which utilize the Assuan protocol as described by the aegypten project. Ping? Looks good. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: R: [ITP] talkfilters-3.8.1-1
On 11/9/2009 16:45, Marco Atzeri wrote: --- Sab 7/11/09, JonY ha scritto: Hi, This utility transforms English text into stereotyped dialects. The files are underhttp://www.cadforte.com/cygwin-uploader/. Unfortunately, its not browsable, here is the file list. Hi Jon to make it brownsable, you need to add a index.html file in all the directories. If you make so, than you can just suggest to download with : $ wget -r -np -nH --cut-dirs=2 http://www.cadforte.com/cygwin-uploader/talkfilters/ Eventually to build all the index.html you can reuse the script I am using (put them in your $HOME/bin ) and run dir2html.sh in the main to create all the index.html in the main and in the sub directories. To download them $ wget -r -np -nH --cut-dirs=1 http://matzeri.altervista.org/script/ To create the file list for the mail, you can use a command like: $ find -type f |grep -v index |colrm 1 2 Hi, sorry about that, here is the wget'able list. Attached is the list of files for wget -i, in case the inline list gets mangled. http://www.cadforte.com/cygwin-uploader/talkfilters/libtalkfilters1/libtalkfilters1-2.3.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/libtalkfilters1/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-2.3.8-1-src.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-2.3.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-devel/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-devel/talkfilters-devel-2.3.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/libtalkfilters1/libtalkfilters1-2.3.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/libtalkfilters1/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-2.3.8-1-src.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-2.3.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-devel/setup.hint http://www.cadforte.com/cygwin-uploader/talkfilters/talkfilters-devel/talkfilters-devel-2.3.8-1.tar.bz2
Re: [ITP] lzip-1.8-1
On 11/8/2009 00:17, JonY wrote: On 11/7/2009 23:29, Christopher Faylor wrote: On Sat, Nov 07, 2009 at 12:28:52PM +0800, JonY wrote: Hi, Lzip is a lossless data compressor based on the LZMA algorithm. It is in Ubuntu:http://packages.ubuntu.com/karmic/lzip The files are underhttp://www.cadforte.com/cygwin-uploader/. Unfortunately, its not browsable, here is the file list. \---lzip lzip-1.8-1-src.tar.bz2 lzip-1.8-1.tar.bz2 setup.hint Example:http://www.cadforte.com/cygwin-uploader/lzip/setup.hint Homepage:http://www.nongnu.org/lzip/lzip.html category: Archive requires: cygwin libgcc1 libstdc++6 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. We already have xz. Why do we need this? cgf Hi, lzip and xz are not exactly compatible. I find that xz has somewhat better compression ratios but lzip has an archive recovery utility. Hi, Following Marco's advice, here is a wget'able list for lzip. http://www.cadforte.com/cygwin-uploader/lzip/lzip-1.8-1-src.tar.bz2 http://www.cadforte.com/cygwin-uploader/lzip/lzip-1.8-1.tar.bz2 http://www.cadforte.com/cygwin-uploader/lzip/setup.hint
[ITP] gobject-introspection
GObject Introspection is a language-agnostic binding tool for GObject-based libraries. It generates typelibs describing the library's API, which can then be read and used through a library (libgirepository) or language bindings thereto (currently available for Python and JavaScript). The typelibs for GLib, various X11 libraries used higher up the stack, and a test module are also included. This is necessary for GNOME 2.28, as Pango builds its typelib concurrently, and PyGObject 2.20 includes Python bindings to libgirepository. GObject Introspection is fairly new, so it only started being packaged in Debian squeeze (testing), Ubuntu jaunty (9.04), and Fedora 9. ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-Everything1.0/girepository-Everything1.0-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-Everything1.0/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-GLib2.0/girepository-GLib2.0-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-GLib2.0/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-x11/girepository-x11-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/girepository-x11/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/gobject-introspection-0.6.5-2-src.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/gobject-introspection-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/libgirepository1.0-devel/libgirepository1.0-devel-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/libgirepository1.0-devel/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/libgirepository1.0_0/libgirepository1.0_0-0.6.5-2.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/libgirepository1.0_0/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/GNOME2.28/GNOME/gobject-introspection/setup.hint Yaakov Cygwin/X
binutils-2.19.51-1 issue
Hi All, If we try to build gettext-runtime utility with current binutils package then we will have runtime error like this: D:\...n\_gettext-runtime\usr-win32\bingettext.exe 2 [main] gettext 5924 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 2365 [main] gettext 5924 open_stackdumpfile: Dumping stack trace to gettext.exe.stackdump D:\...n\_gettext-runtime\usr-win32\bin This is binutils cofflink.c error. So this issue can be fixed by following patch: diff -b --unified -Nr binutils-2.19.51-1-orig/bfd/cofflink.c binutils-2.19.51-1/bfd/cofflink.c --- binutils-2.19.51-1-orig/bfd/cofflink.c 2009-06-13 22:36:21.0 +0400 +++ binutils-2.19.51-1/bfd/cofflink.c 2009-11-10 01:13:10.200030900 +0300 @@ -2956,7 +2956,7 @@ See also linker.c: generic_link_check_archive_element. */ asection *sec; struct coff_link_hash_entry *h2 = -input_bfd-tdata.coff_obj_data-sym_hashes[ +h-auxbfd-tdata.coff_obj_data-sym_hashes[ h-aux-x_sym.x_tagndx.l]; if (!h2 || h2-root.type == bfd_link_hash_undefined) Related links: http://www.mail-archive.com/cyg...@cygwin.com/msg101432.html http://sourceware.org/ml/binutils-cvs/2009-10/msg00010.html http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/cofflink.c.diff?cvsroot=srcr1=1.71r2=1.72 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=srcr1=1.4803r2=1.4804 Please apply this patch and update the cygwin-1.7 packages. Best Regards, Andrey
Re: [1.7] ITP: pinentry
Corinna Vinschen wrote: On Nov 6 15:33, Charles Wilson wrote: Charles Wilson wrote: http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-0.7.6-2-src.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-gtk2/pinentry-gtk2-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-gtk2/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-qt3/pinentry-qt3-0.7.6-2.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/pinentry-qt3/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/pinentry/setup.hint Ping? Looks good. Thanks. I've uploaded it and update cygwin-pkg-maint. I'll send out an announcement tomorrow. -- Chuck
Re: [1.7] ITP: libassuan
Corinna Vinschen wrote: On Nov 6 15:35, Charles Wilson wrote: Charles Wilson wrote: http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-1.0.5-1-src.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-1.0.5-1.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-devel/libassuan-devel-1.0.5-1.tar.bz2 http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/libassuan-devel/setup.hint http://cygutils.fruitbat.org/ITP-gnupg2/release/libassuan/setup.hint Packaging looks ok, but is it really necessary to have a libassuan package which only provides the documentation which you then need if you install libassuan-devel? I think it would be simpler to haave only a libassuan-devel package. Having foo-VER-src.tar.bz2 foo-devel-VER.tar.bz2 without also having foo-VER.tar.bz2 always seems to cause problems for me, and shipping foo-devel-VER.tar.bz2 foo-devel-VER-src.tar.bz2 just seems like cheating somehow. Otherwise I'm wondering if the requirements aren't upside down. You require libassuan (the docs) if you install libassuan-devel, but not vice versa... I've removed the interdependent requires: entirely. Anyway, it's ok to upload as you prefer. Done, and updated cygwin-pkg-maint. Announcement tomorrow. -- Chuck
Re: binutils-2.19.51-1 issue
On Tue, Nov 10, 2009 at 02:27:02AM +0300, Andrew V. Kosteltsev wrote: Hi All, If we try to build gettext-runtime utility with current binutils package then we will have runtime error like this: Sorry but you're sending email to the wrong mailing list. If you are reporting a cygwin problem please use the cygwin mailing list. If you have a binutils patch then please send it to the binutils mailing list. cgf
Re: 'run xterm' fails to open a window
no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... thanks and regards JLM On Fri, Nov 6, 2009 at 7:40 PM, Mike Ayers mike_ay...@tvworks.com wrote: From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of jean-luc malet Sent: Thursday, November 05, 2009 6:18 AM gvim.bat : c:\cygwin\bin\run -p /bin gvim Try: c:\cygwin\bin\run -p /bin:/usr/X11R6/bin gvim HTH, Mike -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- 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/
Option to disable PRIMARY clipboard
Hi, Is there a way to disable the PRIMARY clipboard ? Would a patch like that http://sourceware.org/ml/cygwin-xfree/2003-06/msg00148.html (with a command line option) be accepted ? Thanks, -- Corentin Chary http://xf.iksaif.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] [1.7] Updated: xorg-server-1.7.1-2
The following package has been updated for Cygwin 1.7: * xorg-server-1.7.1-2 This package contains XWin and the other X.Org X11 servers. The following patches has been added in this release: - Don't exit with error if locale is not supported by X11. (Fixes compatibility with cygwin 1.7.0-63.) - Update and better organize options in -help output and XWin(1) manpage. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] [1.7] Updated: xcompmgr-1.1.5-1
The following package has been updated for Cygwin 1.7: * xcompmgr-1.1.5-1 xcompmgr is a simple Compositing manager. This is an update to the latest upstream version. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[1.7] Cygwin/X crashes with latest server, cygwin
I updated Cygwin 1.7 with Yakov's fix the LANG problem. It's unstable, the first time I created an Xterm, the server crashed (seg fault): I tried to create another Xterm, but it's hanging my system. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning 2009-11-09 13:43:34 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2009-11-09 13:43:34 _XSERVTransOpen: transport open failed for inet6/LTDENA-REISERT:0 2009-11-09 13:43:34 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2009-11-09 13:43:34 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-09 13:43:34 (II) xorg.conf is not supported 2009-11-09 13:43:34 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-09 13:43:34 winPrefsLoadPreferences: /cygdrive/c/Home/.XWinrc 2009-11-09 13:43:34 LoadPreferences: Done parsing the configuration file... 2009-11-09 13:43:34 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:34 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-09 13:43:34 winDetectSupportedEngines - DirectDraw installed 2009-11-09 13:43:35 winDetectSupportedEngines - DirectDraw4 installed 2009-11-09 13:43:35 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-09 13:43:35 winSetEngine - Multi Window or Rootless = ShadowGDI 2009-11-09 13:43:35 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2009-11-09 13:43:35 winAllocateFBShadowGDI - Creating DIB with width: 3200 height: 1200 depth: 32 2009-11-09 13:43:35 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-09 13:43:35 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2009-11-09 13:43:35 null screen fn ReparentWindow 2009-11-09 13:43:35 null screen fn RestackWindow 2009-11-09 13:43:35 InitQueue - Calling pthread_mutex_init 2009-11-09 13:43:35 InitQueue - pthread_mutex_init returned 2009-11-09 13:43:35 InitQueue - Calling pthread_cond_init 2009-11-09 13:43:35 InitQueue - pthread_cond_init returned 2009-11-09 13:43:35 winInitMultiWindowWM - Hello 2009-11-09 13:43:35 winInitMultiWindowWM - Calling pthread_mutex_lock () 2009-11-09 13:43:35 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-09 13:43:35 winMultiWindowXMsgProc - Hello 2009-11-09 13:43:35 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2009-11-09 13:43:35 MIT-SHM extension disabled due to lack of kernel support 2009-11-09 13:43:35 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-09 13:43:35 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-09 13:43:35 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 2009-11-09 13:43:36 winPointerWarpCursor - Discarding first warp: 1600 600 2009-11-09 13:43:36 (--) 16 mouse buttons found 2009-11-09 13:43:36 (--) Setting autorepeat to delay=250, rate=25 2009-11-09 13:43:36 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-09 13:43:36 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-09 13:43:36 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winInitMultiWindowWM - Warning: Locale not supported by X. 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:37 winInitMultiWindowWM - DISPLAY=:0.0 2009-11-09 13:43:37 winMultiWindowXMsgProc - Warning: locale not supported by X 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. 2009-11-09 13:43:39 winProcEstablishConnection - Hello 2009-11-09 13:43:39 winInitClipboard () 2009-11-09 13:43:39 winClipboardProc - Hello 2009-11-09 13:43:39 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-09 13:43:39 winProcEstablishConnection - winInitClipboard returned. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winMultiWindowXMsgProc - DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc - Warning: Locale not supported by X. 2009-11-09 13:43:39 winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc - DISPLAY=:0.0
Re: [1.7] Cygwin/X crashes with latest server, cygwin
Setting: LANG=en_US.UTF-8 seems to avoid the problem. - Jim On Mon, Nov 9, 2009 at 1:48 PM, Jim Reisert AD1C jjreis...@alum.mit.edu wrote: I updated Cygwin 1.7 with Yakov's fix the LANG problem. It's unstable, the first time I created an Xterm, the server crashed (seg fault): I tried to create another Xterm, but it's hanging my system. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning 2009-11-09 13:43:34 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2009-11-09 13:43:34 _XSERVTransOpen: transport open failed for inet6/LTDENA-REISERT:0 2009-11-09 13:43:34 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2009-11-09 13:43:34 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-09 13:43:34 (II) xorg.conf is not supported 2009-11-09 13:43:34 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-09 13:43:34 winPrefsLoadPreferences: /cygdrive/c/Home/.XWinrc 2009-11-09 13:43:34 LoadPreferences: Done parsing the configuration file... 2009-11-09 13:43:34 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:34 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-09 13:43:34 winDetectSupportedEngines - DirectDraw installed 2009-11-09 13:43:35 winDetectSupportedEngines - DirectDraw4 installed 2009-11-09 13:43:35 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-09 13:43:35 winSetEngine - Multi Window or Rootless = ShadowGDI 2009-11-09 13:43:35 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2009-11-09 13:43:35 winAllocateFBShadowGDI - Creating DIB with width: 3200 height: 1200 depth: 32 2009-11-09 13:43:35 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-09 13:43:35 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2009-11-09 13:43:35 null screen fn ReparentWindow 2009-11-09 13:43:35 null screen fn RestackWindow 2009-11-09 13:43:35 InitQueue - Calling pthread_mutex_init 2009-11-09 13:43:35 InitQueue - pthread_mutex_init returned 2009-11-09 13:43:35 InitQueue - Calling pthread_cond_init 2009-11-09 13:43:35 InitQueue - pthread_cond_init returned 2009-11-09 13:43:35 winInitMultiWindowWM - Hello 2009-11-09 13:43:35 winInitMultiWindowWM - Calling pthread_mutex_lock () 2009-11-09 13:43:35 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-09 13:43:35 winMultiWindowXMsgProc - Hello 2009-11-09 13:43:35 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2009-11-09 13:43:35 MIT-SHM extension disabled due to lack of kernel support 2009-11-09 13:43:35 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-09 13:43:35 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-09 13:43:35 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 2009-11-09 13:43:36 winPointerWarpCursor - Discarding first warp: 1600 600 2009-11-09 13:43:36 (--) 16 mouse buttons found 2009-11-09 13:43:36 (--) Setting autorepeat to delay=250, rate=25 2009-11-09 13:43:36 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-09 13:43:36 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-09 13:43:36 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winInitMultiWindowWM - Warning: Locale not supported by X. 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:37 winInitMultiWindowWM - DISPLAY=:0.0 2009-11-09 13:43:37 winMultiWindowXMsgProc - Warning: locale not supported by X 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. 2009-11-09 13:43:39 winProcEstablishConnection - Hello 2009-11-09 13:43:39 winInitClipboard () 2009-11-09 13:43:39 winClipboardProc - Hello 2009-11-09 13:43:39 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-09 13:43:39 winProcEstablishConnection - winInitClipboard returned. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winMultiWindowXMsgProc - DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc -
Re: 'run xterm' fails to open a window
jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_console.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-11-09 15:38:36 Modified files: winsup/cygwin : ChangeLog fhandler_console.cc Log message: * fhandler_console.cc (fhandler_console::read): Restrict generating META key sequences to singlebyte input chars. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4712r2=1.4713 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_console.cc.diff?cvsroot=srcr1=1.205r2=1.206
src/winsup/cygwin ChangeLog path.cc syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-11-09 19:46:36 Modified files: winsup/cygwin : ChangeLog path.cc syscalls.cc Log message: * path.cc (symlink_info::check_reparse_point): Always check SubstituteName for volume string to recognize volume mount points. Reuse subst when calling sys_wcstombs. * syscalls.cc (rename): Set errno to EBUSY when trying to rename volume mount points. Explain why. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4713r2=1.4714 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.571r2=1.572 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.545r2=1.546
Re: console enhancements: mouse events
On Nov 8 23:02, t...@towo.net wrote:
Corinna Vinschen schrieb:
signed copyright assignment form (http://cygwin.com/assign.txt) in place.
It's in the envelope.
Cool.
Open the console properties dialog and disable QuickEdit.
I had checked the properties and nothing worked. QuickEdit enabled
would disable mouse control for applications altogether; it is
disabled so mouse click and move events can be processed but the
mouse wheel still scrolls the window instead, on that machine.
Weird. It works for me. Andy seems to be right about drivers.
For backward compatibility, I'd prefer if ESC[9m would still do the same.
As long as ESC[9m isn't desparately needed for something else...
I thought there might be this objection as it is in theory an
incompatible change but it's not in practice since dim mode doesn't
work anyway; so I think this change towards the standard assignment
should be done before someone in the future may fix dim mode to work
after which it would actually be an incompatible change.
* Maybe the escape sequences of shifted function keys should be
modified to comply with those of the Linux console?
Aren't they compatible with xterm? I don't think it's a terrible good
idea to change that.
No, they are not:
Linux console
F1..F12 ^[[[A ^[[[B ^[[[C ^[[[D ^[[[E ^[[17~ ^[[18~ ^[[19~
^[[20~ ^[[21~ ^[[23~ ^[[24~
shift-F1..F8^[[25~ ^[[26~ ^[[28~ ^[[29~ ^[[31~ ^[[32~ ^[[33~ ^[[34~
cygwin console
F1..F12 ^[[[A ^[[[B ^[[[C ^[[[D ^[[[E ^[[17~ ^[[18~ ^[[19~
^[[20~ ^[[21~ ^[[23~ ^[[24~
shift-F1..F10 ^[[23~ ^[[24~ ^[[25~ ^[[26~ ^[[28~ ^[[29~ ^[[31~
^[[32~ ^[[33~ ^[[34~
[...]
Furthermore, xterm and mintty also support
Control- and Alt-modified F-keys and combinations of the modifiers.
So if your preference would be to follow xterm here anyway, I would
welcome this change and provide a patch; I think this change can be
done without compatibility trouble in mainstream applications
since the shifted F-keys are not listed in the cygwin terminfo
entry.
Ooookey, if they aren't listed in terminfo anyway, I have no problems
to change them. But we should stick to following the Linux console,
I guess.
Except for one of them, this doesn't work with a german keyboard and
german keyboard layout. In this case, the respective keysequences
C+^, C+AltGr+sz, C+AG+8, C+AG+9 return nothing at all. Only the
C+S+- key returns ^_, as expected.
Thanks Andy for pointing to the part of mintty code handling this.
However, the whole function there looks too complex for a quick
copy-paste-patch. Maybe later...
No copy-paste, please. Mintty is under GPL, so we can't just take
the code, unless Andy gives us explicit permission to do so.
or Andy might like to factor out
the mapping part in a way directly reusable for the cygwin console?
(Or should it be left as is because it's just the console...?)
Well, it works in some way. I played around with ToUnicode over the
weekend, and I didn't get it working as expected. Take, for instance,
this (simplified):
if (input_rec.Event.KeyEvent.dwControlKeyState
(LEFT_CTRL_PRESSED | RIGHT_CTRL_PRESSED))
{
GetKeyboardState (state);
state[VK_CONTROL] = state[VK_LCONTROL] = state[VK_RCONTROL] = 0;
if (ToUnicode (input_rec.Event.KeyEvent.wVirtualKeyCode,
input_rec.Event.KeyEvent.wVirtualScanCode,
state, wcbuf, 8, 0) 0)
switch (wcbuf[0])
{
case L'[' ... L'_':
got_one = true;
break;
[...]
}
[...]
When I pressed Strg-^ on a german keyboard layout (left of the 1
key), I constantly got Ctrl-\ instead of Ctrl-^. Weird.
- Pressing something like Alt-ö on a German keyboard leaves an
illegal UTF-8 sequence (the second byte of the respective
sequence) in input, apparently because Alt-0xC3 is handled
somehow. Don't know, though, whether this is a cygwin
console issue or maybe a readline issue.
Alt is converted to a leading ESC. I don't know how to fix that for
non-ASCII chars, yet.
For non-ASCII it works fine, thanks to Andy for clarifying; I could
Erm... sorry, but do we really talk about the same? If you press
Alt-ö, the console generates the sequence ESC 0xc3 0xb6. That's not
desired so I'm contemplating the idea to skip the keypress if the
resulting multibyte char is 1 byte. This restricts ESC-somekey
either to explicit function key sequences (ESC-[-foo, etc), or
to just two byte sequences like ESC-A, ESC-0, ESC-;, etc.
have checked this myself, even within bash, by simply typing
Control-V Alt-ö. It does not work however, even for ASCII
characters, for characters produced with AltGr, e.g. Alt-AltGr-Q
where AltGr-Q is @ (German keyboard). Andy got this to work in
mintty (I think with some other subtle trick after I challenged him
for it IIRC); it does not work in xterm either.
That's potentially too tricky for the current code. And,
Re: console enhancements: mouse events
On Mon, Nov 09, 2009 at 02:35:51PM +0100, Corinna Vinschen wrote: On Nov 8 23:02, t...@towo.net wrote: Corinna Vinschen schrieb: Ooookey, if they aren't listed in terminfo anyway, I have no problems to change them. But we should stick to following the Linux console, I guess. I agree. I'm surprised that we've had the function keys wrong all these years. * I intended to implement cursor position reports and noticed that their request ESC[6n is already handled in the code; it does not work, however, so I started to debug it: This needs some more debugging, I guess. Do you have an opinion about my theory that the wrong read-ahead buffer is being filled here (stdout vs. stdin)? If so, I still have no clue how to proceed; maybe you'd kindly give a hint how to access the stdin buffer / stdin fhandler? I have no opinion yet, since I don't know this part of the code good enough. IIUC you think that the readahead buffer of the wrong fhandle_console is filled, the one connected with stdout, not the one connected with stdin, right? I'm still struggling to understand what a stdout read-ahead buffer might be. Could you point to the place in the code where you see the problem? cgf
Re: console enhancements: mouse events
On Nov 9 09:54, Christopher Faylor wrote: On Mon, Nov 09, 2009 at 02:35:51PM +0100, Corinna Vinschen wrote: On Nov 8 23:02, t...@towo.net wrote: Corinna Vinschen schrieb: Ooookey, if they aren't listed in terminfo anyway, I have no problems to change them. But we should stick to following the Linux console, I guess. I agree. I'm surprised that we've had the function keys wrong all these years. * I intended to implement cursor position reports and noticed that their request ESC[6n is already handled in the code; it does not work, however, so I started to debug it: This needs some more debugging, I guess. Do you have an opinion about my theory that the wrong read-ahead buffer is being filled here (stdout vs. stdin)? If so, I still have no clue how to proceed; maybe you'd kindly give a hint how to access the stdin buffer / stdin fhandler? I have no opinion yet, since I don't know this part of the code good enough. IIUC you think that the readahead buffer of the wrong fhandle_console is filled, the one connected with stdout, not the one connected with stdin, right? I'm still struggling to understand what a stdout read-ahead buffer might be. Could you point to the place in the code where you see the problem? As far as I understand it: Application writes ESC [ 6 n to stdout which is connected to one fhandler_console. Cygwin creates the reply and copies it into the readahead buffer of this very fhandler_console. But that's not the same fhandler_console which is connected to stdin, which is the fhandler the application reads the reply from. So the reply never makes it to the application. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: console enhancements: mouse events
Corinna Vinschen schrieb: On Nov 9 09:54, Christopher Faylor wrote: On Mon, Nov 09, 2009 at 02:35:51PM +0100, Corinna Vinschen wrote: On Nov 8 23:02, t...@towo.net wrote: Corinna Vinschen schrieb: Ooookey, if they aren't listed in terminfo anyway, I have no problems to change them. But we should stick to following the Linux console, I guess. I agree. I'm surprised that we've had the function keys wrong all these years. * I intended to implement cursor position reports and noticed that their request ESC[6n is already handled in the code; it does not work, however, so I started to debug it: This needs some more debugging, I guess. Do you have an opinion about my theory that the wrong read-ahead buffer is being filled here (stdout vs. stdin)? If so, I still have no clue how to proceed; maybe you'd kindly give a hint how to access the stdin buffer / stdin fhandler? I have no opinion yet, since I don't know this part of the code good enough. IIUC you think that the readahead buffer of the wrong fhandle_console is filled, the one connected with stdout, not the one connected with stdin, right? I'm still struggling to understand what a stdout read-ahead buffer might be. Could you point to the place in the code where you see the problem? As far as I understand it: Application writes ESC [ 6 n to stdout which is connected to one fhandler_console. Cygwin creates the reply and copies it into the Yes, see fhandler_console::char_command, case 'n', small_sprintf, then puts_readahead (buf); readahead buffer of this very fhandler_console. Yes, I traced ralen and raixput in fhandler_base::put_readahead (in fhandler.cc) and could watch the buffer being filled with e.g. 7 bytes. But that's not the same fhandler_console which is connected to stdin, which is the fhandler the application reads the reply from. I also traced ralen and raixget in fhandler_base::get_readahead and saw the buffer empty immediately after the filling with 7 bytes; I had also traced other places where ralen could be reset, with no occurrence logged between the two traces mentioned. So the reply never makes it to the application. Thomas
Encoding problem
Under 1.7.0-063: I use the following code to remove files: find . -name .svn | xargs -L 1 rm -rf and the result is all file without Chinese code in the path are removed but others not. I guess maybe 'find' and 'xargs' or 'rm' didn't use the same encoding make those problem. -- 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: Encoding problem
Sorry, my mistake. 2009/11/9 Huang Bambo bambo.hu...@gmail.com: Under 1.7.0-063: I use the following code to remove files: find . -name .svn | xargs -L 1 rm -rf and the result is all file without Chinese code in the path are removed but others not. I guess maybe 'find' and 'xargs' or 'rm' didn't use the same encoding make those problem. -- 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
ls and cd command don't use the same encoding
Under 1.7.0-63,64 With mintty export LANG=en_US.UTF-8 export LC_TYPE=zh_CN.UTF-8 ls can list some directory in Chinese but cd command can't enter it. If I set encoding to GBK, mintty works fine but ssh can't do so then. $ cd /tmp [ba...@revenco-bambo /tmp] $ ls 中文 [ba...@revenco-bambo /tmp] $ cd / (I use tab key to auto fill this line) [ba...@revenco-bambo /tmp/] $ cd .. [ba...@revenco-bambo /tmp] $ cd 中文 (I input the directory name, but can't enter) -bash: cd: 中文: No such file or directory [ba...@revenco-bambo /tmp] $ env | grep LAN NLS_LANG=AMERICAN_AMERICA.ZHS32GB18030 LANG=en_US.UTF-8 [ba...@revenco-bambo /tmp] $ env | grep LC LC_TYPE=zh_CN.UTF-8 [ba...@revenco-bambo /tmp] -- 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: Pseudo-terminal will not be allocated because stdin is not a terminal.
A closer look at Process Explorer revealed the cause of the problem: rxvt.exe37328 444,184 K 4,740 K 6,332 K me 1,630 C:\cygwin17\bin\rxvt.exe --geometry 170x60+0+0 -e ssh -Y lab1 rxvt.exe 52768 431,304 K 3,628 K 3,940 K me 1,023 C:\cygwin17\bin\rxvt.exe ssh.exe 86408 449,540 K 3,704 K 6,224 K me 1,807 C:\cygwin\bin\ssh.exe -Y lab1 It was running the ssh from Cygwin 1.5 ! It is true that c:\cygwin\bin is in the Windows path although I don't understand why rxvt didn't pick its own ssh. I assume rxvt wasn't started in C:\cygwin17\bin (the shortcut launched C:\cygwin17\bin\run.exe in C:\cygwin17) The easy fix is to make sure rxvt launches its own ssh by supplying an absolute path: Target: C:\cygwin17\bin\run.exe rxvt --geometry 170x60+0+0 -e /usr/bin/ssh -Y lab1 Csaba -- Life is complex, with real and imaginary parts -- 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-63
On Nov 8 19:12, Eric Backus wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: On Nov 7 20:38, Eric Backus wrote: Jim Reisert AD1C jjreisert at alum.mit.edu writes: How do I make this work, while maintaining: LANG=en_US.UTF-8 - Jim You might try LANG=en_us.UTF-8 (Note the lower-case us). It seems to That's not correct. The result is that the locale will still be C. The above LANG setting will be refused since the territory part of the locale specifier must be uppercase. See http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html#setup-locale-ov Corinna OK, my bad. Sorry. I must say I find the ls behavior quite confusing. It appears that *any* valid setting of LANG other than C results in the iso time style, and --time- style=locale never has any effect regardless of the setting of LANG. Feature? or defect? Dunno, but I admit that I like the ISO date much better anyway. It's more clear and independent of locale specific differences to express a date. 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] BUG - GREP slows to a crawl with large number of matches on a single file
On Nov 8 18:41, Jim Reisert AD1C wrote: Corinna, the new grep works super great - thanks! I'm glad to read that, but I only debugged the problem. The Fedora fix was applied by Chris. 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
pgrep does not terminate if processes are suspended
Hi, pgrep from the procps package does not terminate when I suspend processes (which you can do for instance do with Sysinternal's Process Explorer). It does not happen when I use Ctrl+Z in a shell to suspend a process. This is a bit of a problem to me as I have pgrep in my shell initialization file and starting a new shell will simply never finish when any process is in suspended state. Thorsten -- 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: gcc4-java: gcjh will not run
Yaakov (Cygwin/X) wrote:
$ gcjh-4 --help
Caused by: java.util.MissingResourceException: Bundle
gnu.classpath.tools.common.Messages not found for locale C._US by
classloader
gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Yeh, confirmed, but I don't know what it means. I tried setting LANG and
LC_ALL to en_US or en_UK and apart from the locale in the not-found exception
becoming a bit saner, it still didn't work.
I don't know how this stuff is supposed to work yet though. I think this
means that there should be some subclasses of
gnu.classpath.tools.common.Messages present, named according to language
codes, but I have no idea yet where they're supposed to come from. Maybe Eric
B. can advise us here, I see his name all over the resourcebundle code...
cheers,
DaveK
--
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: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)
On Nov 8 14:07, Charles Wilson wrote: Corinna Vinschen wrote: On Nov 8 14:56, Corinna Vinschen wrote: Btw., the check for mmap in grep's configure file is broken. It tries to mmap to a fixed address formerly allocated via malloc(). This doesn't work on Windows. An autoconf run with a newer version of autoconf would be nice. I just found that the latest autoconf *still* has this broken test for mmap, which basically calls data2 = malloc (size); mmap(data2, ...); Why has this test never been fixed? Chuck? ...err, 'cause I didn't realize it was a problem. I see that cygport has hidden this for years: # AC_HAVE_MMAP fails despite a working mmap, so we force this to yes # (see http://www.cygwin.com/ml/cygwin/2004-09/msg00741.html # and following thread for details) export ac_cv_func_mmap_fixed_mapped=yes; NTTAWWT, but it never triggered my gee I ought to fix that reflex. I agree this should be fixed, but I'm leery of changing an autoconf test without knowing how that change will affect the other 9,236 platforms The problem in this testcase is the fact that it calls malloc, then computes the next page-aligned free address after the mallocated area and then tries to mmap to this address with MAP_FIXED set. Sure, this *might* work, and it works on most systems, but there's no reason at all to *expect* that it works since it only works by chance. The memory addresses can be taken by anything and to require that an arbitrary fixed address is available to mmap is just plain wrong. From the Linux man page: MAP_FIXED [...] If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is discouraged. Since autoconf is supposed to help applications to be more portable, it's not really feasible, IMHO, that autoconf requires a non-portable feature to work. It's frustrating that mmap() and even mmap(MAP_FIXED) works fine on Cygwin, just not in the non-portable way it's tested in the autoconf test. Maybe we need two mmap tests in autconf, one for mmap in general, the other for MAP_FIXED iisues. I think this is an issue for the autoconf list as a whole. Would you -- or Eric -- care to raise it there? Especially as you seemed to have quite strong feelings about it back in 2004: http://www.cygwin.com/ml/cygwin/2004-09/msg00753.html I had hoped that you, as the autoconf maintainer, would put this upstream... 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: Finding junction points in cygwin
On Nov 9 07:51, Andy Koppe wrote: 2009/11/9 aputerguy: Does cygwin have any ability to find/identify NTFS junction points? This would be useful so that you don't inadvertently mistreat them thinking they are regular files or directories. They appear as symbolic links. Dunno how to tell them from other sorts of shortcuts. Not quite. Directory junctions appear as symlinks. Volume junctions are treated as simple directories since they are for all practically purposes the same as Unix mount points. 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: ls and cd command don't use the same encoding
2009/11/9 Huang Bambo: Under 1.7.0-63,64 With mintty export LANG=en_US.UTF-8 export LC_TYPE=zh_CN.UTF-8 ls can list some directory in Chinese but cd command can't enter it. Works fine here, including completion. What mintty version are you using and what's your character set setting on the 'Text' page of mintty's options? Where do you set LANG and LC_CTYPE? Andy -- 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: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/9/2009 4:59 AM: I just found that the latest autoconf *still* has this broken test for mmap, which basically calls data2 = malloc (size); mmap(data2, ...); Why has this test never been fixed? Chuck? ...err, 'cause I didn't realize it was a problem. I see that cygport has hidden this for years: # AC_HAVE_MMAP fails despite a working mmap, so we force this to yes # (see http://www.cygwin.com/ml/cygwin/2004-09/msg00741.html # and following thread for details) export ac_cv_func_mmap_fixed_mapped=yes; NTTAWWT, but it never triggered my gee I ought to fix that reflex. I agree this should be fixed, but I'm leery of changing an autoconf test without knowing how that change will affect the other 9,236 platforms The problem in this testcase is the fact that it calls malloc, then computes the next page-aligned free address after the mallocated area and then tries to mmap to this address with MAP_FIXED set. Sure, this *might* work, and it works on most systems, but there's no reason at all to *expect* that it works since it only works by chance. The memory addresses can be taken by anything and to require that an arbitrary fixed address is available to mmap is just plain wrong. From the Linux man page: MAP_FIXED [...] If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is discouraged. Since autoconf is supposed to help applications to be more portable, it's not really feasible, IMHO, that autoconf requires a non-portable feature to work. It's frustrating that mmap() and even mmap(MAP_FIXED) works fine on Cygwin, just not in the non-portable way it's tested in the autoconf test. Maybe we need two mmap tests in autconf, one for mmap in general, the other for MAP_FIXED iisues. I think this is an issue for the autoconf list as a whole. Would you -- or Eric -- care to raise it there? Especially as you seemed to have quite strong feelings about it back in 2004: http://www.cygwin.com/ml/cygwin/2004-09/msg00753.html I had hoped that you, as the autoconf maintainer, would put this upstream... It's an upstream issue now ;) The problem is that I need some more advice from the cygwin list on how best to fix the test to pass on cygwin by default. I'm hoping to release autoconf 2.65 this week, so a speedy fix to help this issue go away before the release would be extra nice. - -- 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/ iEYEARECAAYFAkr4D/sACgkQ84KuGfSFAYCOjwCghVcvxtUrAPxqB7w+/6gaT+Y/ H0EAoIUsDfqQ42NzKa8olQtBdhkvVS1f =36fe -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
Re: gcc4-java: gcjh will not run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dave Korn on 11/9/2009 5:05 AM: Yeh, confirmed, but I don't know what it means. I tried setting LANG and LC_ALL to en_US or en_UK and apart from the locale in the not-found exception becoming a bit saner, it still didn't work. I don't know how this stuff is supposed to work yet though. I think this means that there should be some subclasses of gnu.classpath.tools.common.Messages present, named according to language codes, but I have no idea yet where they're supposed to come from. Maybe Eric B. can advise us here, I see his name all over the resourcebundle code... It's been years since I touched ResourceBundle, and that was back when I understood less about locales. I would probably be shooting in the dark just as much as you, unfortunately. - -- 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/ iEYEARECAAYFAkr4EJkACgkQ84KuGfSFAYC6DwCfeA1UEZxXnwexMwgfhWKeJ6vt XuYAn3We7AbdJm+u/jcostJGhdNDQgp9 =5O47 -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
Re: [1.7] Updated: cygwin-1.7.0-63
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Reisert AD1C on 11/6/2009 11:38 AM: In particular, --time-style in an alias, or TIME_STYLE in your environment, is your friend. Thanks, Eric. I tried this but could not get what I wanted: LTDENA-REISERT:c/Home ls -al --time-style=posix-long-iso -rwx-- 1 reisertDomain Users3326 2009-10-30 12:51 .XWinrc -rwx-- 1 reisertUsers663 2009-02-26 10:37 .Xdefaults From the info link you sent me, it says: `posix-STYLE' List POSIX-locale timestamps if the `LC_TIME' locale category is POSIX, STYLE timestamps otherwise. For example, the `posix-long-iso' style lists timestamps like `Mar 30 2002' and `Mar 30 23:45' when in the POSIX locale, and like `2002-03-30 23:45' otherwise. I must not be in a POSIX LOCALE, then. LC_TIME isn't defined, nor is LOCALE. Correct - if LC_ALL, LC_TIME, and LANG are all undefined, then you are in the C.UTF-8 locale (cygwin's default), which, since it is not C, is not _the_ POSIX locale. Likewise, if LANG is en_US.UTF-8, but LC_ALL and LC_TIME are unset, then you are in the en_US.UTF-8 locale, which is not the POSIX locale. How do I make this work, while maintaining: LANG=en_US.UTF-8 Well, did you try setting LC_TIME=C? That would mean that LC_TIME is then POSIX, overriding LANG; and as long as LC_ALL is unset, then that would make the difference. Or, you could use TIME_STYLE='+%b %e %Y %b %e %H:%M' to force the POSIX interpretation regardless of locale. - -- 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/ iEYEARECAAYFAkr4EkUACgkQ84KuGfSFAYDlzQCfWQMdyvD0q0+GPgsc4dDY7lH9 v2EAn0Gf5ydK3EXSdRuwxcDk6TA6AM3P =kWjz -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
Re: gcc4-java: gcjh will not run
Eric Blake wrote: It's been years since I touched ResourceBundle, and that was back when I understood less about locales. I would probably be shooting in the dark just as much as you, unfortunately. Heh, know how you feel. Found a clue anyway, perhaps: this looks a lot like PR37636, although that was supposed to be happening on 4.4, not 4.3. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636 cheers, DaveK -- 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: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)
On Nov 9 05:50, Eric Blake wrote: According to Corinna Vinschen on 11/9/2009 4:59 AM: MAP_FIXED [...] If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is discouraged. It's an upstream issue now ;) The problem is that I need some more advice from the cygwin list on how best to fix the test to pass on cygwin by default. I'm hoping to release autoconf 2.65 this week, so a speedy fix to help this issue go away before the release would be extra nice. This part of the testcase data2 = (char *) malloc (2 * pagesize); if (!data2) return 1; data2 += (pagesize - ((long int) data2 (pagesize - 1))) (pagesize - 1); if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED, fd, 0L)) return 1; is bad. The chance that the address of data2 is not usable for mmap on Windows/Cygwin is 100%. The problem here is that the generic HAVE_MMAP test tests one certain feature, which is not usable on Windows, and which is non-portable. So, on Cygwin this test always fails and all applications using this test in good faith will never use mmap on Cygwin, just because the single case of mmap private fixed at somewhere already mapped doesn't work. In fact, most applications don't need this case. And grep wouldn't need it either, since the method used in grep would also work if the area hadn't been malloced before, if it would just use the address returned by mmap as buffer. That's why I think we need at least two tests in autoconf, a generic mmap test and a mmap test for the mmap private/shared fixed at somewhere already mapped case, if an application actually insists on using that. 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
[ANNOUNCEMENT] Updated: lftp-4.0.3-1
A new version of lftp, 4.0.3-1, is now available in the Cygwin distribution. This is a new upstream release. It adds Bittorrent support, and fixes some bugs. Please see /usr/share/doc/lftp/README.Cygwin and http://lftp.yar.ru/news.html for the full changelog. The previous Cygwin release was 3.7.15-1. lftp is a sophisticated file transfer program and ftp/http/bittorrent client. It supports multiple network protocols, offers tab completion, command history, job control, and bookmarks, can mirror sites and transfer multiple files in parallel, and keeps trying interrupted operations until it can complete them. Andrew E. Schulman *** 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. -- 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: pgrep does not terminate if processes are suspended
On Mon, Nov 09, 2009 at 12:25:39PM +0100, Thorsten Kampe wrote: Hi, pgrep from the procps package does not terminate when I suspend processes (which you can do for instance do with Sysinternal's Process Explorer). It does not happen when I use Ctrl+Z in a shell to suspend a process. This is a bit of a problem to me as I have pgrep in my shell initialization file and starting a new shell will simply never finish when any process is in suspended state. I can see why this would happen. It's definitely a Cygwin DLL bug but I think that fixing it will probably have to wait until 1.7 is released. 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: pgrep does not terminate if processes are suspended
On Mon, Nov 09, 2009 at 10:00:52AM -0500, Christopher Faylor wrote: On Mon, Nov 09, 2009 at 12:25:39PM +0100, Thorsten Kampe wrote: Hi, pgrep from the procps package does not terminate when I suspend processes (which you can do for instance do with Sysinternal's Process Explorer). It does not happen when I use Ctrl+Z in a shell to suspend a process. This is a bit of a problem to me as I have pgrep in my shell initialization file and starting a new shell will simply never finish when any process is in suspended state. I can see why this would happen. It's definitely a Cygwin DLL bug but I think that fixing it will probably have to wait until 1.7 is released. So that I don't forget this, I've added this as bugzilla bug #10928: http://sourceware.org/bugzilla/show_bug.cgi?id=10928 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: Finding junction points in cygwin
Corinna Vinschen writes Not quite. Directory junctions appear as symlinks. Volume junctions are treated as simple directories since they are for all practically purposes the same as Unix mount points. But I still see several issues at least with directory junctions. 1. When I use junction.exe to make a junction with a regular file, the junction shows up as a regular file under cygwin. When I make a junction to a directory, the junction shows up as a directory. In particular, I don't see symlinks in either case. 2. Shouldn't we have a way of identify and/or differentiating junctions from their targets. For example, cygwin (appropriately) doesn't allow you to remove junctions using 'rm' (either files or directories). But if I am writing code to manipulate files, I would like to be able to identify junctions pro-actively rather than retroactively by the fact that I can't remove them. 3. Moving a junction, moves the target file. And leaves the junction itself 'unlinked'. I'm not sure this is the logical behavior expected, particularly if it is supposed to act like a symlink. Because with symlinks, 'mv' moves the link not the target. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26269606.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: Finding junction points in cygwin
Actually the behavior is even stranger... renaming and then deleting junctions creates spurious directories. echo This is a test file | targetfile mkdir targetdir echo This is a test dir file | targetdir/targetdirfile junction.exe junctionfile targetfile junction.exe junctiondir targetdir ls -Ag drwxr-xr-x 1 None 0 2009-11-09 11:56 junctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 junctionfile drwxr-xr-x 1 None 0 2009-11-09 11:56 targetdir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 targetfile mv junctionfile newjunctionfile mv junctiondir newjunctiondir ls -Ag drwxr-xr-x 1 0 2009-11-09 11:57 junctiondir/ drwxr-xr-x 1 0 2009-11-09 11:57 junctionfile/ drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile junction.exe -d junctionfile junction.exe -d junctiondir ls -Ag drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile drwx--+ 1 None 0 2009-11-09 12:01 targetdir/ drwx--+ 1 None 0 2009-11-09 12:01 targetfile/ Now this seems to be sheer madness. The original file and directory names have reappeared! However 'targetdir' is now empty and 'targetfile' is also an (empty) directory! ls -Ag targetdir targetfile newjunctiondir newjunctiondir: total 1 -rw-r--r-- 1 None 24 2009-11-09 11:56 targetdirfile targetdir: total 0 Interestingly, in Windows explorer, renaming seems to do the right thing - it renames the target. Interestingly, Windows explorer allows both file and directory junctions to be removed (though it displays file junctions as non-openable directories). Not sure why it does this since I thought junctions could only be deleted using '-d'. So it seems to me, we have the following conclusions: - cygwin treatment of junctions is not consistent with Windows or with notion of symlinks. It also leaves weird residua after renaming junctions. - Windows junctions are also messed up but not as much targetfile: total 0 -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270112.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: Finding junction points in cygwin
On Nov 9 08:51, aputerguy wrote: Corinna Vinschen writes Not quite. Directory junctions appear as symlinks. Volume junctions are treated as simple directories since they are for all practically purposes the same as Unix mount points. But I still see several issues at least with directory junctions. 1. When I use junction.exe to make a junction with a regular file, the junction shows up as a regular file under cygwin. When I make a junction to a directory, the junction shows up as a directory. In particular, I don't see symlinks in either case. Are you running Cygwin 1.5.25? If so, yes, Cygwin 1.5.25 doesn't know anything about junctions or native symlinks. It only sees what is visible through the Win32 API. Btw., while directory junctions can point to files, they are always treated as directories by the Win32 API. There's no way to access the target file of such a directory junction from non-Cygwin applications like Windows Explorer or CMD. It's not really supported to do so, and it's kind of schizophrenic that the CMD builtin command mklink allows to create such directory junctions pointing to files. 2. Shouldn't we have a way of identify and/or differentiating junctions from their targets. For example, cygwin (appropriately) doesn't allow you to remove junctions using 'rm' (either files or directories). But if I am writing code to manipulate files, I would like to be able to identify junctions pro-actively rather than retroactively by the fact that I can't remove them. Try Cygwin 1.7. It recognizes directory junctions as symlinks. 3. Moving a junction, moves the target file. And leaves the junction itself 'unlinked'. I'm not sure this is the logical behavior expected, particularly if it is supposed to act like a symlink. Because with symlinks, 'mv' moves the link not the target. Try Cygwin 1.7. It recognizes directory junctions as symlinks. 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: Finding junction points in cygwin
On Nov 9 09:17, aputerguy wrote: Actually the behavior is even stranger... renaming and then deleting junctions creates spurious directories. echo This is a test file | targetfile mkdir targetdir echo This is a test dir file | targetdir/targetdirfile junction.exe junctionfile targetfile junction.exe junctiondir targetdir ls -Ag drwxr-xr-x 1 None 0 2009-11-09 11:56 junctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 junctionfile drwxr-xr-x 1 None 0 2009-11-09 11:56 targetdir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 targetfile mv junctionfile newjunctionfile mv junctiondir newjunctiondir ls -Ag drwxr-xr-x 1 0 2009-11-09 11:57 junctiondir/ drwxr-xr-x 1 0 2009-11-09 11:57 junctionfile/ drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile junction.exe -d junctionfile junction.exe -d junctiondir ls -Ag drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/ -rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile drwx--+ 1 None 0 2009-11-09 12:01 targetdir/ drwx--+ 1 None 0 2009-11-09 12:01 targetfile/ Now this seems to be sheer madness. Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in Cygwin 1.7. The only difference between your and my run is that I'm using the cmd mklink builtin rather than the junction tool, like this: $ cmd /c mklink /j junctionfile targetfile Junction created for junctionfile === targetfile $ cmd /c mklink /j junctiondir targetdir Junction created for junctiondir === targetdir BLODA? 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: Finding junction points in cygwin
Corinna writes.. Try Cygwin 1.7. It recognizes directory junctions as symlinks. $ uname -r 1.7.0(0.214/5/3) But don't see any symlinks... -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270509.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: Finding junction points in cygwin
Corinna Vinschen writes... Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in Cygwin 1.7. The only difference between your and my run is that I'm using the cmd mklink builtin rather than the junction tool, like this: BLODA? I don't know... I don't have a lot of BLODA on my machine... I found the problem once and then I reproduced it in order to cut paste the problem to the list. But when I just tried to reproduce it again, I couldn't. So let's ignore that problem for now or maybe it is related to whatever weirdness is causing my Cygwin 1.7 not to recognize junctions as symlinks. Any suggestions on how to troubleshoot why I'm not seeing the symlinks? And just to confirm, 'find' also recognizes the junctions as files and directories - not as symlinks. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270902.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: Finding junction points in cygwin
On Nov 9 09:39, aputerguy wrote: Corinna writes.. Try Cygwin 1.7. It recognizes directory junctions as symlinks. $ uname -r 1.7.0(0.214/5/3) But don't see any symlinks... Uh, I see. Don't use the junction tool, use cmd's mklink instead. junction.exe creates directory symlinks which can't be easily recognized as directory junctions, at least not using the default technique. I'll look into supporting these weird junctions as well. 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] BUG - GREP slows to a crawl with large number of matches on a single file
Corinna writes: I'm glad to read that, but I only debugged the problem. The Fedora fix was applied by Chris. Well it works for me too and as the OP of the problem, I extend my thanks to both of you and all the others who helped in debugging and coming up with such a quick fix. My only remaining question is can we assume that this bug (or bad coding) is grep-specific or is it likely to rear its head in other core *nix utilities that use UTF-8? -- View this message in context: http://old.nabble.com/1.7--BUG---GREP-slows-to-a-crawl-with-large-number-of-matches-on-a-single-file-tp26224019p26271227.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: Finding junction points in cygwin
2009/11/9 Corinna Vinschen: aputerguy: But don't see any symlinks.. Uh, I see. Don't use the junction tool, use cmd's mklink instead. Was mklink introduced with Vista? It's not present on XP. The alternative there is linkd.exe, available as part of the freely downloadable Windows Server 2003 Resource Kit Tools. I checked again that Cygwin recognizes links created by linkd.exe as symlinks. Sorry for not trying junction.exe before posting. Andy -- 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: Finding junction points in cygwin
Corinna writes: Uh, I see. Don't use the junction tool, use cmd's mklink instead. junction.exe creates directory symlinks which can't be easily recognized as directory junctions, at least not using the default technique. I'll look into supporting these weird junctions as well. Thanks. Something should be done here I think because otherwise you can really unwittingly create a mess if someone else has created junctions and you start renaming and moving files around. The behavior seems to be unexpected and potentially destructive. Better to not allow any (destructive) cygwin operations on such files than to have such unnatural behavior. I will look into getting mklink for XP in the meantime. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26272067.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: Finding junction points in cygwin
I have been googling on junction.exe and mklink. Since they both create reparse points, in what way are the reparse points different to the extent that cygwin recognizes those from mklink but not those form junction.exe. The nice thing though about junction.exe is that it uses the *nix like '-d' flag rather than the dos-like '/D' flag that mklink seems to use. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26272231.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: Finding junction points in cygwin
On Nov 9 19:09, Corinna Vinschen wrote: On Nov 9 09:39, aputerguy wrote: Corinna writes.. Try Cygwin 1.7. It recognizes directory junctions as symlinks. $ uname -r 1.7.0(0.214/5/3) But don't see any symlinks... Uh, I see. Don't use the junction tool, use cmd's mklink instead. junction.exe creates directory symlinks which can't be easily recognized as directory junctions, at least not using the default technique. I'll look into supporting these weird junctions as well. Not quite as weird. The test got actually simpler now. I also set the return code of rename(2) to EBUSY when you try to rename a volume junction. Otherwise Windows returns an error code equivalent to EXDEV and mv(1) starts to move the directory over by copying its entire content (cross-device mv). HTH, 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: Finding junction points in cygwin
On Nov 9 18:59, Andy Koppe wrote: 2009/11/9 Corinna Vinschen: aputerguy: But don't see any symlinks.. Uh, I see. Don't use the junction tool, use cmd's mklink instead. Was mklink introduced with Vista? It's not present on XP. The Yes, it has been added to cmd in Vista. Unfortunately it's a builtin, not a stand-alone tool. 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: Finding junction points in cygwin
On Nov 9 11:16, aputerguy wrote: I will look into getting mklink for XP in the meantime. There's no mklink for XP. It's a cmd builtin in Vista and later. 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: Finding junction points in cygwin
On Nov 9 11:27, aputerguy wrote: The nice thing though about junction.exe is that it uses the *nix like '-d' flag rather than the dos-like '/D' flag that mklink seems to use. mklink /d creates a symlink with a directory DOS attribute, it does not delete the symlink. 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] BUG - GREP slows to a crawl with large number of matches on a single file
On Nov 9 10:22, aputerguy wrote: My only remaining question is can we assume that this bug (or bad coding) is grep-specific or is it likely to rear its head in other core *nix utilities that use UTF-8? Who knows? Nobody is immune against creating bad code, right? 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-63
On Mon, Nov 9, 2009 at 5:59 AM, Eric Blake e...@byu.net wrote: Well, did you try setting LC_TIME=C? That would mean that LC_TIME is then POSIX, overriding LANG; and as long as LC_ALL is unset, then that would make the difference. That worked fine, thanks. The real fix will be when I can eliminate LANG=en_US.UTF-8 and still have the Cygwin/X server start - Jim -- Jim Reisert AD1C, jjreis...@alum.mit.edu, http://www.ad1c.us -- 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: Finding junction points in cygwin
More generally, could someone point me to a single source that can accurately compare and contrast the following notions of links in cygwin/windoze: 1. Hard links (ln) 2. Soft links (ln -s) - Old style - New style 3. Windows shortcuts 4. Junctions created by junction.exe 5. Reparse points created by linkd.exe 6. Other types of reparse points? 5. Mount points created by cygwin mount 6. Mount points created by mountvol 7. Letter drives created by dosdev 8. Letter drives created using Administrative Tools computer management 9. Other types of mounting? I know that some of the above only work on files, some only on directories, some only on shares, etc. but there is a lot of overlap and a nice table would be very helpful. Personally, I'm sure I don't understand all the differences, subtleties, limitations, and when to use which one. I'm also left with the feeling that Microsoft just keeps throwing new flavors of links and mounts rather than going with a consistent approach but maybe I'm just biased to *nix. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273372.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
[1.7] Cygwin/X crashes with latest server, cygwin
I updated Cygwin 1.7 with Yakov's fix the LANG problem. It's unstable, the first time I created an Xterm, the server crashed (seg fault): I tried to create another Xterm, but it's hanging my system. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xf...@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning 2009-11-09 13:43:34 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2009-11-09 13:43:34 _XSERVTransOpen: transport open failed for inet6/LTDENA-REISERT:0 2009-11-09 13:43:34 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2009-11-09 13:43:34 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-09 13:43:34 (II) xorg.conf is not supported 2009-11-09 13:43:34 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-09 13:43:34 winPrefsLoadPreferences: /cygdrive/c/Home/.XWinrc 2009-11-09 13:43:34 LoadPreferences: Done parsing the configuration file... 2009-11-09 13:43:34 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:34 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-09 13:43:34 winDetectSupportedEngines - DirectDraw installed 2009-11-09 13:43:35 winDetectSupportedEngines - DirectDraw4 installed 2009-11-09 13:43:35 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-09 13:43:35 winSetEngine - Multi Window or Rootless = ShadowGDI 2009-11-09 13:43:35 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2009-11-09 13:43:35 winAllocateFBShadowGDI - Creating DIB with width: 3200 height: 1200 depth: 32 2009-11-09 13:43:35 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-09 13:43:35 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2009-11-09 13:43:35 null screen fn ReparentWindow 2009-11-09 13:43:35 null screen fn RestackWindow 2009-11-09 13:43:35 InitQueue - Calling pthread_mutex_init 2009-11-09 13:43:35 InitQueue - pthread_mutex_init returned 2009-11-09 13:43:35 InitQueue - Calling pthread_cond_init 2009-11-09 13:43:35 InitQueue - pthread_cond_init returned 2009-11-09 13:43:35 winInitMultiWindowWM - Hello 2009-11-09 13:43:35 winInitMultiWindowWM - Calling pthread_mutex_lock () 2009-11-09 13:43:35 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-09 13:43:35 winMultiWindowXMsgProc - Hello 2009-11-09 13:43:35 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2009-11-09 13:43:35 MIT-SHM extension disabled due to lack of kernel support 2009-11-09 13:43:35 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-09 13:43:35 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-09 13:43:35 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 2009-11-09 13:43:36 winPointerWarpCursor - Discarding first warp: 1600 600 2009-11-09 13:43:36 (--) 16 mouse buttons found 2009-11-09 13:43:36 (--) Setting autorepeat to delay=250, rate=25 2009-11-09 13:43:36 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-09 13:43:36 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-09 13:43:36 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winInitMultiWindowWM - Warning: Locale not supported by X. 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:37 winInitMultiWindowWM - DISPLAY=:0.0 2009-11-09 13:43:37 winMultiWindowXMsgProc - Warning: locale not supported by X 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. 2009-11-09 13:43:39 winProcEstablishConnection - Hello 2009-11-09 13:43:39 winInitClipboard () 2009-11-09 13:43:39 winClipboardProc - Hello 2009-11-09 13:43:39 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-09 13:43:39 winProcEstablishConnection - winInitClipboard returned. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winMultiWindowXMsgProc - DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc - Warning: Locale not supported by X. 2009-11-09 13:43:39 winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc - DISPLAY=:0.0
Re: Finding junction points in cygwin
Corinna Vinschen writes: On Nov 9 11:27, aputerguy wrote: The nice thing though about junction.exe is that it uses the *nix like '-d' flag rather than the dos-like '/D' flag that mklink seems to use. mklink /d creates a symlink with a directory DOS attribute, it does not delete the symlink. I'm sorry I meant linkd.exe. It uses the '/D' flag to delete rather than *nix-like '-d' -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273434.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: Finding junction points in cygwin
And also add to the below list: 10. mklink -- More generally, could someone point me to a single source that can accurately compare and contrast the following notions of links in cygwin/windoze: 1. Hard links (ln) 2. Soft links (ln -s) - Old style - New style 3. Windows shortcuts 4. Junctions created by junction.exe 5. Reparse points created by linkd.exe 6. Other types of reparse points? 5. Mount points created by cygwin mount 6. Mount points created by mountvol 7. Letter drives created by dosdev 8. Letter drives created using Administrative Tools computer management 9. Other types of mounting? I know that some of the above only work on files, some only on directories, some only on shares, etc. but there is a lot of overlap and a nice table would be very helpful. Personally, I'm sure I don't understand all the differences, subtleties, limitations, and when to use which one. I'm also left with the feeling that Microsoft just keeps throwing new flavors of links and mounts rather than going with a consistent approach but maybe I'm just biased to *nix. -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273453.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: [1.7] Cygwin/X crashes with latest server, cygwin
Setting: LANG=en_US.UTF-8 seems to avoid the problem. - Jim On Mon, Nov 9, 2009 at 1:48 PM, Jim Reisert AD1C jjreis...@alum.mit.edu wrote: I updated Cygwin 1.7 with Yakov's fix the LANG problem. It's unstable, the first time I created an Xterm, the server crashed (seg fault): I tried to create another Xterm, but it's hanging my system. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xf...@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1600 h 1200 winInitializeDefaultScreens - Returning 2009-11-09 13:43:34 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2009-11-09 13:43:34 _XSERVTransOpen: transport open failed for inet6/LTDENA-REISERT:0 2009-11-09 13:43:34 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2009-11-09 13:43:34 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-09 13:43:34 (II) xorg.conf is not supported 2009-11-09 13:43:34 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-09 13:43:34 winPrefsLoadPreferences: /cygdrive/c/Home/.XWinrc 2009-11-09 13:43:34 LoadPreferences: Done parsing the configuration file... 2009-11-09 13:43:34 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:34 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-09 13:43:34 winDetectSupportedEngines - DirectDraw installed 2009-11-09 13:43:35 winDetectSupportedEngines - DirectDraw4 installed 2009-11-09 13:43:35 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-09 13:43:35 winSetEngine - Multi Window or Rootless = ShadowGDI 2009-11-09 13:43:35 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2009-11-09 13:43:35 winAllocateFBShadowGDI - Creating DIB with width: 3200 height: 1200 depth: 32 2009-11-09 13:43:35 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-09 13:43:35 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2009-11-09 13:43:35 null screen fn ReparentWindow 2009-11-09 13:43:35 null screen fn RestackWindow 2009-11-09 13:43:35 InitQueue - Calling pthread_mutex_init 2009-11-09 13:43:35 InitQueue - pthread_mutex_init returned 2009-11-09 13:43:35 InitQueue - Calling pthread_cond_init 2009-11-09 13:43:35 InitQueue - pthread_cond_init returned 2009-11-09 13:43:35 winInitMultiWindowWM - Hello 2009-11-09 13:43:35 winInitMultiWindowWM - Calling pthread_mutex_lock () 2009-11-09 13:43:35 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-09 13:43:35 winMultiWindowXMsgProc - Hello 2009-11-09 13:43:35 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2009-11-09 13:43:35 MIT-SHM extension disabled due to lack of kernel support 2009-11-09 13:43:35 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-09 13:43:35 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-09 13:43:35 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-09 13:43:35 [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! 2009-11-09 13:43:36 winPointerWarpCursor - Discarding first warp: 1600 600 2009-11-09 13:43:36 (--) 16 mouse buttons found 2009-11-09 13:43:36 (--) Setting autorepeat to delay=250, rate=25 2009-11-09 13:43:36 (--) winConfigKeyboard - Layout: 0409 (0409) 2009-11-09 13:43:36 (--) Using preset keyboard for English (USA) (409), type 4 2009-11-09 13:43:36 Rules = base Model = pc105 Layout = us Variant = none Options = none 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winInitMultiWindowWM - Warning: Locale not supported by X. 2009-11-09 13:43:37 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_lock () returned. 2009-11-09 13:43:37 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:37 winInitMultiWindowWM - DISPLAY=:0.0 2009-11-09 13:43:37 winMultiWindowXMsgProc - Warning: locale not supported by X 2009-11-09 13:43:37 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. 2009-11-09 13:43:39 winProcEstablishConnection - Hello 2009-11-09 13:43:39 winInitClipboard () 2009-11-09 13:43:39 winClipboardProc - Hello 2009-11-09 13:43:39 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-09 13:43:39 winProcEstablishConnection - winInitClipboard returned. 2009-11-09 13:43:39 winGetDisplay: DISPLAY=:0.0 2009-11-09 13:43:39 winMultiWindowXMsgProc - DISPLAY=:0.0 2009-11-09 13:43:39 winClipboardProc -
[ANNOUNCEMENT] [1.7] mpclib-0.8-1
mpclib-0.8-1 has been released for cygwin 1.7. PACKAGE DESCRIPTION === Homepage: http://www.multiprecision.org/mpc Download: http://www.multiprecision.org/index.php?prog=mpcpage=download License: Gnu Lesser General Public License, version 2.1 or later MPC is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result. It is built upon and follows the same principles as MPFR. With this release, MPC provides all C99 complex math functions. MPC is a prerequisite for gcc-4.5. See: - http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00671.html - http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00804.html - http://gcc.gnu.org/ml/gcc/2009-11/msg00102.html INSTALL OR UPGRADE NOTES Upstream bumped the shared library version number for 0.7. I chose not to bump the DLL version as from limited testing it appears to binary compatible with mpclib-0.6-1. Version 0.8, Dianthus deltoides, released in November 2009, comes with the following new features: New functions: Inverse trigonometric functions: mpc_asin, mpc_acos, mpc_atan, mpc_asinh, mpc_acosh, mpc_atanh Power functions: mpc_pow_d, mpc_pow_ld, mpc_pow_si, mpc_pow_ui, mpc_pow_z, mpc_pow_fr Bug fixes: ui_div: real divisor -- 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: Finding junction points in cygwin
On Mon, Nov 9, 2009 at 8:46 PM, aputerguy wrote: More generally, could someone point me to a single source that can accurately compare and contrast the following notions of links in cygwin/windoze: 1. Hard links (ln) 2. Soft links (ln -s) - Old style - New style 3. Windows shortcuts 4. Junctions created by junction.exe 5. Reparse points created by linkd.exe 6. Other types of reparse points? 5. Mount points created by cygwin mount 6. Mount points created by mountvol 7. Letter drives created by dosdev 8. Letter drives created using Administrative Tools computer management 9. Other types of mounting? I know that some of the above only work on files, some only on directories, some only on shares, etc. but there is a lot of overlap and a nice table would be very helpful. Personally, I'm sure I don't understand all the differences, subtleties, limitations, and when to use which one. I'm also left with the feeling that Microsoft just keeps throwing new flavors of links and mounts rather than going with a consistent approach but maybe I'm just biased to *nix. There is also the 'subst' command that lets you create a directory and point it to a drive. C:\subst /? Associates a path with a drive letter. SUBST [drive1: [drive2:]path] SUBST drive1: /D drive1:Specifies a virtual drive to which you want to assign a path. [drive2:]path Specifies a physical drive and path you want to assign to a virtual drive. /D Deletes a substituted (virtual) drive. Type SUBST with no parameters to display a list of current virtual drives. -- 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: Finding junction points in cygwin
DePriest, Jason R. wrote: There is also the 'subst' command that lets you create a directory and point it to a drive. OK - now I am truly tearing out my hair as 'subst' makes #11. I'm thinking a table with the following columns would be very helpful: A. Name of command B. Source (e.g., Cygwin 1.x+, Windows ver X-Y, etc.) C. Targets (e.g., files, directories, volumes) D. Type of link/junction/mount point E. *nix analogy and compatibility (including whether exact or similar) F. Advantages relative to analogous concepts G. Limitations, gotchas, etc. H. How (or even if) handled by cygwin -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26274197.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: New gcc-4 compile error w/getc and isspace
Dave Korn wrote: Vin Shelton wrote: t2.c: In function ‘tst’: t2.c:9: error: lvalue required as left operand of assignment Did something recently change in the ctype.h or stdio.h header files to cause this? Thanks, Dave! - Vin -- 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
Even after I install ALL the 'Devel' packages, still receive no acceptable C compiler found in $PATH error
Hello World!!! I've installed all the Devel packages, plus a few extra. However, whenever I try to compile a Linux tool with: ./configure, I get the following output; c...@panarchy /cygdrive/n/rancid-2.3.2 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gmake... no checking for make... /usr/bin/make checking whether /usr/bin/make sets $(MAKE)... yes checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/cygdrive/n/rancid-2.3.2': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details. Here is an ls of my /usr/bin folder: http://pastebin.com/m3da9e20d Please tell me how I can get rancid to compile through cygwin. Thanks in advance, Panarchy PS: I've also tried install MinGW, to no avail. -- 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: Even after I install ALL the 'Devel' packages, still receive no acceptable C compiler found in $PATH error
Chip Panarchy wrote: Hello World!!! I've installed all the Devel packages, plus a few extra. However, whenever I try to compile a Linux tool with: ./configure, I get the following output; c...@panarchy /cygdrive/n/rancid-2.3.2 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gmake... no checking for make... /usr/bin/make checking whether /usr/bin/make sets $(MAKE)... yes checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/cygdrive/n/rancid-2.3.2': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details. Here is an ls of my /usr/bin folder: http://pastebin.com/m3da9e20d Please tell me how I can get rancid to compile through cygwin. Thanks in advance, my first step would be to remove the mingw and then re-run setup.exe, re-installing the required packages... it configures fine for me. I don't get this warning either - configure: WARNING: `missing' script is too old or missing http://pastebin.com/m6e134682 -- 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: Even after I install ALL the 'Devel' packages, still receive no acceptable C compiler found in $PATH error
On 11/09/2009 09:35 PM, Chip Panarchy wrote: Hello World!!! I've installed all the Devel packages, plus a few extra. However, whenever I try to compile a Linux tool with: ./configure, I get the following output; c...@panarchy /cygdrive/n/rancid-2.3.2 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gmake... no checking for make... /usr/bin/make checking whether /usr/bin/make sets $(MAKE)... yes checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/cygdrive/n/rancid-2.3.2': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details. Here is an ls of my /usr/bin folder: http://pastebin.com/m3da9e20d Please tell me how I can get rancid to compile through cygwin. 'gcc' comes from one of the 'gcc*-core' packages. I'd recommend reading and following the problem reporting guidelines found at the link below if you need to follow-up with the list on this issue. http://cygwin.com/problems.html PS: I've also tried install MinGW, to no avail. That's a separate issue that you'd need to take up with the MinGW folks if you feel there's something wrong there. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Even after I install ALL the 'Devel' packages, still receive no acceptable C compiler found in $PATH error
Thanks everyone for your prompt reply. Reid: Here is the config.log http://pastebin.com/d6e533e7e I have since manually gone install mingw with msys, which got me a little further, but failed at 'diff'. I think that I will create another topic specifiying RANCID in the subject line. Best Regards, Chip D. Panarchy On Tue, Nov 10, 2009 at 2:11 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: On 11/09/2009 09:35 PM, Chip Panarchy wrote: Hello World!!! I've installed all the Devel packages, plus a few extra. However, whenever I try to compile a Linux tool with: ./configure, I get the following output; c...@panarchy /cygdrive/n/rancid-2.3.2 $ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes configure: WARNING: `missing' script is too old or missing checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gmake... no checking for make... /usr/bin/make checking whether /usr/bin/make sets $(MAKE)... yes checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/cygdrive/n/rancid-2.3.2': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details. Here is an ls of my /usr/bin folder: http://pastebin.com/m3da9e20d Please tell me how I can get rancid to compile through cygwin. 'gcc' comes from one of the 'gcc*-core' packages. I'd recommend reading and following the problem reporting guidelines found at the link below if you need to follow-up with the list on this issue. http://cygwin.com/problems.html PS: I've also tried install MinGW, to no avail. That's a separate issue that you'd need to take up with the MinGW folks if you feel there's something wrong there. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
[Help-Please] Compiling RANCID on Cygwin
Good Afternoon, =Quick summary=; RANCID - Really Awesome New Cisco confIg Differ RANCID monitors a router's (or more generally a device's) configuration, including software and hardware (cards, serial numbers, etc) and uses CVS (Concurrent Version System) or Subversion to maintain history of changes. RANCID does this by the very simple process summarized here: • login to each device in the router table (router.db), • run various commands to get the information that will be saved, • cook the output; re-format, remove oscillating or incrementing data, • email any differences (sample) from the previous collection to a mail list, • and finally commit those changes to the revision control system http://www.shrubbery.net/rancid/#osystems I'm trying to compile RANCID through Cygwin for use on Windows. Any help with this would be appreciated. Thanks in advance, Chip D. Panarchy -- 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: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 11/9/2009 7:05 AM:
This part of the testcase
data2 = (char *) malloc (2 * pagesize);
if (!data2)
return 1;
data2 += (pagesize - ((long int) data2 (pagesize - 1))) (pagesize - 1);
if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_FIXED, fd, 0L))
return 1;
is bad. The chance that the address of data2 is not usable for mmap on
Windows/Cygwin is 100%.
But in testing this further, I discovered that you CAN do:
data2 = mmap(...);
munmap (data2,...);
mmap (data2, ... MAP_FIXED)
and get success on cygwin. So I will be updating autoconf accordingly,
based on the STD below. Unfortunately, it looks like I also found a hole
in cygwin. Consider this (borrowing heavily from the autoconf test that I
am fixing):
#include stdio.h
#include sys/types.h
#include sys/stat.h
#include stdlib.h
#include string.h
#include unistd.h
#include fcntl.h
#include sys/mman.h
int
main (int argc, char **argv)
{
char *data, *data2, *data3;
int i, pagesize;
int fd, fd2;
pagesize = getpagesize ();
/* First, make a file with some known garbage in it. */
data = (char *) malloc (pagesize);
if (!data)
return 1;
for (i = 0; i pagesize; ++i)
*(data + i) = rand ();
umask (0);
fd = creat (conftest.mmap, 0600);
if (fd 0)
return 2;
if (write (fd, data, pagesize) != pagesize)
return 3;
close (fd);
/* Next, check that a page is zero-filled if not backed by a file. */
fd2 = open (conftest.txt, O_RDWR | O_CREAT | O_TRUNC, 0600);
if (fd2 0)
return 11;
data2 = ;
if (write (fd2, data2, 1) != 1)
return 12;
else
/* We expect mmap to succeed, but reads to give SIGBUS, since mapped
region is an entire page beyond bounds of mapped file. */
;
data2 = mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
if (data2 == MAP_FAILED)
return 14;
printf (mapped %p\n, data2);
for (i = 0; i pagesize; ++i)
if (*(data2 + i))
{
printf (%p, %x\n, data2 + i, *(data2 + i));
return 15;
}
close (fd2);
if (argc 1)
munmap (data2, pagesize);
/* Next, try to mmap the file at a fixed address which already has
something else allocated at it. If we can, also make sure that
we see the same garbage. */
fd = open (conftest.mmap, O_RDWR);
if (fd 0)
return 4;
if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_FIXED, fd, 0L))
return 6;
for (i = 0; i pagesize; ++i)
if (*(data + i) != *(data2 + i))
{
printf (%p, exp %x, got %x\n, data2 + i, *(data + i), *(data2 + i));
return 7;
}
/* Finally, make sure that changes to the mapped area do not
percolate back to the file as seen by read(). (This is a bug on
some variants of i386 svr4.0.) */
for (i = 0; i pagesize; ++i)
*(data2 + i) = *(data2 + i) + 1;
data3 = (char *) malloc (pagesize);
if (!data3)
return 8;
if (read (fd, data3, pagesize) != pagesize)
return 9;
for (i = 0; i pagesize; ++i)
if (*(data + i) != *(data3 + i))
return 10;
close (fd);
return 0;
}
This test behaves differently on Linux than on cygwin; on Linux, both
'./foo' and './foo 1' give status 0, but on cygwin, './foo' gives status
6, and only './foo 1' succeeds. In other words, the second mmap fails if
there is no intermediate munmap.
POSIX apparently allows cygwin's behavior:
If MAP_FIXED is set, mmap() may return MAP_FAILED and set errno to
[EINVAL]. If a MAP_FIXED request is successful, the mapping established by
mmap() replaces any previous mappings for the pages in the range
[pa,pa+len) of the process.
However, since we already have to maintain a list of mappings in order to
implement fork(), it seems like it would be easy to fix cygwin to
implicitly munmap anything that would otherwise be in the way of a
subsequent MAP_FIXED request, rather than blindly calling
NtMapViewOfSection and failing because of the overlap, so that we could be
even more like Linux behavior.
That's why I think we need at least two tests in autoconf, a generic
mmap test and a mmap test for the mmap private/shared fixed at
somewhere already mapped case, if an application actually insists on
using that.
In the case of the autoconf test, I think a single test is still
sufficient, once it is fixed to be portable to what POSIX requires.
gnulib provides a more interesting test, for whether MMAP_ANON works.
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/mmap-anon.m4
- --
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/
iEYEARECAAYFAkr46LMACgkQ84KuGfSFAYCBrwCgsu2/rWozZs/1R33RaAlUwHow
Re: Finding junction points in cygwin
On Mon, Nov 09, 2009 at 01:41:50PM -0800, aputerguy wrote: DePriest, Jason R. wrote: There is also the 'subst' command that lets you create a directory and point it to a drive. OK - now I am truly tearing out my hair as 'subst' makes #11. I'm thinking a table with the following columns would be very helpful: A. Name of command B. Source (e.g., Cygwin 1.x+, Windows ver X-Y, etc.) C. Targets (e.g., files, directories, volumes) D. Type of link/junction/mount point E. *nix analogy and compatibility (including whether exact or similar) F. Advantages relative to analogous concepts G. Limitations, gotchas, etc. H. How (or even if) handled by cygwin It's not clear whom you are expecting to prepare this comprehensive list. For Cygwin we clearly want you to use our symlinks. It's a bonus that Corinna has implemented any functionality for anything else at all. 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: Broken autoconf mmap test
Corinna Vinschen wrote: I had hoped that you, as the autoconf maintainer, would put this upstream... Well, I would have done so...but you guys beat me to it. I go off-net for a day or so, and lookit what happens...I think I need to go off-net more often! -- Chuck -- 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: Broken autoconf mmap test (was Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[please limit replies about the patch itself to autoconf-patches]
According to Corinna Vinschen on 11/9/2009 7:05 AM:
This part of the testcase
data2 = (char *) malloc (2 * pagesize);
if (!data2)
return 1;
data2 += (pagesize - ((long int) data2 (pagesize - 1))) (pagesize - 1);
if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_FIXED, fd, 0L))
return 1;
is bad. The chance that the address of data2 is not usable for mmap on
Windows/Cygwin is 100%. The problem here is that the generic HAVE_MMAP
test tests one certain feature, which is not usable on Windows, and which
is non-portable.
MAP_FIXED appears to be more portable when the fixed address was obtained
from a previous mmap call. Therefore, this patch fixes the macro as well
as making diagnosing configure failures more accurately pinpoint why they
are declaring failure. I don't have access to HP-UX 11, which is another
platform where AC_FUNC_MMAP was failing; I would appreciate if someone
else could see if this makes a difference there. But I have verified that
this now sets HAVE_MMAP for cygwin 1.5.x and cygwin 1.7 where the old
version failed, and that it does not change behavior on Linux or OpenBSD.
- --
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/
iEYEARECAAYFAkr484kACgkQ84KuGfSFAYDCIgCbBl/eHS9C9acPwXp5Krk7KAeF
zAIAoMBEbnQm5tLpRDkCFWhEXNieL5cf
=3fYB
-END PGP SIGNATURE-
From fb1f28a2ff2c688e63dc97ece7fde86e16864491 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Mon, 9 Nov 2009 21:45:00 -0700
Subject: [PATCH] Fix AC_FUNC_MMAP for cygwin.
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Make the test more
portable: Actually check for sys/param.h, and only use MAP_FIXED
on an address previously returned from mmap.
* THANKS: Update.
Reported by Corinna Vinschen.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog |9 +++
NEWS |3 ++
lib/autoconf/functions.m4 | 55 ++--
3 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4d028c0..77e9d4e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-11-09 Eric Blake e...@byu.net
+
+ Fix AC_FUNC_MMAP for cygwin.
+ * lib/autoconf/functions.m4 (AC_FUNC_MMAP): Make the test more
+ portable: Actually check for sys/param.h, and only use MAP_FIXED
+ on an address previously returned from mmap.
+ * THANKS: Update.
+ Reported by Corinna Vinschen.
+
2009-11-04 Eric Blake e...@byu.net
Redocument AS_DIRNAME, even with its flaws.
diff --git a/NEWS b/NEWS
index 9e7e64c..86a0c3f 100644
--- a/NEWS
+++ b/NEWS
@@ -29,6 +29,9 @@ GNU Autoconf NEWS - User visible changes.
longer mistakenly select a 32-bit type on some compilers (bug present
since macros were introduced in 2.59c).
+** The AC_FUNC_MMAP macro has been fixed to be portable to systems like
+ Cygwin (bug present since macro was introduced in 2.0).
+
** The following documented autotest macros are new:
AT_CHECK_EUNIT
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 946a646..6b6e7fc 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1186,9 +1186,9 @@ AU_ALIAS([AM_FUNC_MKTIME], [AC_FUNC_MKTIME])
#
AN_FUNCTION([mmap], [AC_FUNC_MMAP])
AC_DEFUN([AC_FUNC_MMAP],
-[AC_CHECK_HEADERS(stdlib.h unistd.h)
-AC_CHECK_FUNCS(getpagesize)
-AC_CACHE_CHECK(for working mmap, ac_cv_func_mmap_fixed_mapped,
+[AC_CHECK_HEADERS_ONCE([stdlib.h unistd.h sys/param.h])
+AC_CHECK_FUNCS([getpagesize])
+AC_CACHE_CHECK([for working mmap], [ac_cv_func_mmap_fixed_mapped],
[AC_RUN_IFELSE([AC_LANG_SOURCE([AC_INCLUDES_DEFAULT]
[[/* malloc might have been renamed as rpl_malloc. */
#undef malloc
@@ -1224,11 +1224,6 @@ char *malloc ();
/* This mess was copied from the GNU getpagesize.h. */
#ifndef HAVE_GETPAGESIZE
-/* Assume that all systems that can run configure have sys/param.h. */
-# ifndef HAVE_SYS_PARAM_H
-# define HAVE_SYS_PARAM_H 1
-# endif
-
# ifdef _SC_PAGESIZE
# define getpagesize() sysconf(_SC_PAGESIZE)
# else /* no _SC_PAGESIZE */
@@ -1264,7 +1259,7 @@ main ()
{
char *data, *data2, *data3;
int i, pagesize;
- int fd;
+ int fd, fd2;
pagesize = getpagesize ();
@@ -1277,27 +1272,41 @@ main ()
umask (0);
fd = creat (conftest.mmap, 0600);
if (fd 0)
-return 1;
+return 2;
if (write (fd, data, pagesize) != pagesize)
-return 1;
+return 3;
close (fd);
+ /* Next, check that the tail of a page is zero-filled. File must have
+ non-zero length, otherwise we risk SIGBUS for entire page. */
+ fd2 = open
Re: NTFS Symlinks (reparse point) redux
Corinna Vinschen wrote: On Nov 5 22:39, Larry Hall (Cygwin) wrote: Cygwin 1.7 does recognize reparse points and especially the new NTFS6 symlinks. --- Yeah, I have yet to upgrade...going through throws of machine tantrums now--and OS issues...I hope to give her a spin soon. However, it only reads them, never writes them, for the reasons repeated by cgf and me a couple of times. --- That's fine w/me for the nonce, drives me crazy when I forget about the ones I've created, let alone all the new ones in use in Vista... You just can't use them to store POSIX paths That would tend to confuse win processes... Anyone know what happens under the included POSIX subsystem in Vista (and I assume Win7), when it creates symlinks? I can't imagine they use .lnk file extensions -- but if they use reparse point links, I'd think they'd almost have to store posix path information in them. I wonder if a posix created symlink is compatible (usable) by a dos/win app? Maybe there's something usable from the posix subsystem that would work for both purposes? Just a thought -- I haven't looked into the posix subsystem under vista. *and* allowing interoperability with native Win32 processes, plus the nonsense of coupling them with a user right, plus the super-nonsense only to allow Admins to create them by default. --- Hmmm...can't imagine that being true for the posix symlinks. Maybe posix symlinks only work in posix and aren't true symbolic links recognized by NT. *sigh*. All that together makes them worse than Windows shortcuts and they have not the faintest advantage over Cygwin-only symlinks implemented as files with the SYSTEM DOS attribute set. --- Well -- 1 advantage. They work in cygwin and in windows -- by work, I mean the indirection. Not that every feature one would want works. But all cygwin and dos/windows apps blithely follow the links without knowing they are links. Same can't be said for .lnk based links. *sigh*. -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: Finding junction points in cygwin
Christopher Faylor writes It's not clear whom you are expecting to prepare this comprehensive list. For Cygwin we clearly want you to use our symlinks. It's a bonus that Corinna has implemented any functionality for anything else at all. No real expectations and not a complaint about cygwin. Just more of a frustration of trying to merge the *nix and Windows worlds. My problem is not within cygwin itself -- it's with trying to use cygwin to also do Windoze-related tasks. In particular, I am trying to extend a *nix-focused rsync-based program to do a better job of backing up Windoze systems by capturing as much of the ntfs structure as possible. So, I am trying to understand ACLs, reparse points, the MFT, etc. Cygwin is of course awesome... -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26279378.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
Updated: lftp-4.0.3-1
A new version of lftp, 4.0.3-1, is now available in the Cygwin distribution. This is a new upstream release. It adds Bittorrent support, and fixes some bugs. Please see /usr/share/doc/lftp/README.Cygwin and http://lftp.yar.ru/news.html for the full changelog. The previous Cygwin release was 3.7.15-1. lftp is a sophisticated file transfer program and ftp/http/bittorrent client. It supports multiple network protocols, offers tab completion, command history, job control, and bookmarks, can mirror sites and transfer multiple files in parallel, and keeps trying interrupted operations until it can complete them. Andrew E. Schulman *** 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.
[1.7] mpclib-0.8-1
mpclib-0.8-1 has been released for cygwin 1.7. PACKAGE DESCRIPTION === Homepage: http://www.multiprecision.org/mpc Download: http://www.multiprecision.org/index.php?prog=mpcpage=download License: Gnu Lesser General Public License, version 2.1 or later MPC is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result. It is built upon and follows the same principles as MPFR. With this release, MPC provides all C99 complex math functions. MPC is a prerequisite for gcc-4.5. See: - http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00671.html - http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00804.html - http://gcc.gnu.org/ml/gcc/2009-11/msg00102.html INSTALL OR UPGRADE NOTES Upstream bumped the shared library version number for 0.7. I chose not to bump the DLL version as from limited testing it appears to binary compatible with mpclib-0.6-1. Version 0.8, Dianthus deltoides, released in November 2009, comes with the following new features: New functions: Inverse trigonometric functions: mpc_asin, mpc_acos, mpc_atan, mpc_asinh, mpc_acosh, mpc_atanh Power functions: mpc_pow_d, mpc_pow_ld, mpc_pow_si, mpc_pow_ui, mpc_pow_z, mpc_pow_fr Bug fixes: ui_div: real divisor
