Re: Ready for test coreutils-5.2.0-1
Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) I think the way other packages have dealt with this problem is by renaming with a prefix (corekill like prockill) or just not installing them. I don't want to speak for Chuck, but the other option is, if he gets a new cygutils ready with Harold's mkshortcut patch he could also remove readlink from cygutils. -- Chuck
Re: Ready for test coreutils-5.2.0-1
On Fri, Mar 12, 2004 at 03:45:44AM -0500, Charles Wilson wrote: Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. Agree. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. Let's not distribute it. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. Agree. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) Do we need two of these? Let's not distribute it. cgf
.rdata section in Cygwin executables?
The emacs recompile fails because there is a section in the initially built emacs.exe named .rdata that the unexec() code for Cygwin is not expecting. The section appears to have something to do with exception handling and is only 1k in size. I'm reading up on this at the moment, but a couple questions occur to me that someone here might be able to answer off the top of their head: - can .rdata just be combined with the preceeding .data section? - perhaps there is a way to do this with the linker so I don't have to change the emacs unexec() code? -- Joe Buehler
Pending PPL
Hi, all, FYI, I'm still working on the PPL, but doing it properly is taking more time than I anticipated. I now appreciate Dan's efforts even more... :-) The PPL *is* coming, just not as soon as I expected. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: .rdata section in Cygwin executables?
Joe Buehler wrote: The emacs recompile fails because there is a section in the initially built emacs.exe named .rdata that the unexec() code for Cygwin is not expecting. The section appears to have something to do with exception handling and is only 1k in size. .rdata is a section where read-only data, such as constants, is stored. Most modern OSes and toolchain try to put as much info as possible to read-only segments of binary image because it reduce memory required by programs to run (when program is fork()ed, for instance, read-only pages may be shared between processes) On linux such section is called .rodata, so probably you can take a look how linux version of emacs deals with that. I'm reading up on this at the moment, but a couple questions occur to me that someone here might be able to answer off the top of their head: - can .rdata just be combined with the preceeding .data section? It's possible, but it's not the Right Way (tm). - perhaps there is a way to do this with the linker so I don't have to change the emacs unexec() code? You may write your own linker script so that all rdata section will be put to .data when emacs.exe is linked, but again, it doesn't look as the proper way to deal with the problem. egor.
Re: .rdata section in Cygwin executables?
Egor Duda wrote: You may write your own linker script so that all rdata section will be put to .data when emacs.exe is linked, but again, it doesn't look as the proper way to deal with the problem. According to objdump, there is no readonly flag set for .rdata. Does Windows know about the name .rdata and know that only one copy is needed for multiple emacs processes? Or perhaps Cygwin knows about the name for similar reasons? Or perhaps (gasp) the implementation is not currently complete and .rdata buys me nothing at present? Thanks for the feedback -- I am looking for something easy to do here to get the existing 21.2 emacs back in shape for Cygwin. I already need to rewrite unexec() for the FSF version for copyright reasons and don't really want to spend any time on the current unexec() code -- it's throwaway at some point. -- Joe Buehler
Re: Ready for test coreutils-5.2.0-1
So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint Mark Blackburn Christopher Faylor wrote: On Fri, Mar 12, 2004 at 03:45:44AM -0500, Charles Wilson wrote: Joshua Daniel Franklin wrote: There are also some patches I'm considering adding from fileutils-4.1-2 (proposed-fileutils-patches.txt). I got these by diffing fileutils-4.1 with the src package for fileutils-4.1-2. I was hoping that the previous maintainer could comment on these patches so I could figure out if they are relevant for the coreutils package. If they the changes haven't been made in the coreutils source, why not continue using the Cygwin-specific patches? agree. Any cygwin-specific patches that were in the old packages that haven't been pushed back all the way to official coreutils, need to be kept in cygwin's coreutils. Agree. There are still conflicting binaries: kill.exe : cygwin-1.5.7-1 this is _probably_ cygwin specific. I'd either rename the coreutils one to 'corekill', or not distribute coreutil's kill at all. Let's not distribute it. readlink.exe : cygutils-1.2.4-1 I'll go ahead and remove this program from cygutils -- but only *after* coreutils has made it thru its initial shake-down period. Thus, I won't delay cygutils-1.2.5 waiting for coreutils to finish ITP'ing -- but I'll release cygutils-1.2.6 very soon after coreutils goes 'gold'. Agree. uptime.exe : procps-010801-2 my linux box shows /usr/bin/uptime as part of procps, not coreutils. Another candidate for a rename? (coreps?) Do we need two of these? Let's not distribute it. cgf
Re: .rdata section in cygwin executables?
On Fri, Mar 12, 2004 at 10:28:02AM -0500, Joe Buehler wrote: Egor Duda wrote: You may write your own linker script so that all rdata section will be put to .data when emacs.exe is linked, but again, it doesn't look as the proper way to deal with the problem. According to objdump, there is no readonly flag set for .rdata. Try a binutils from CVS. There was some funkiness with readonly flags in binutils. I don't know if it infects the cygwin version of binutils or not. I keep rebuilding binutils in preparation for a new release but that effort invariably triggers someone sending an interesting new bug or bugfix to the binutils mailing list so I have been waiting for the code to settle down. cgf
Re: Pending PPL
On Fri, 12 Mar 2004, Christopher Faylor wrote: On Fri, Mar 12, 2004 at 09:38:40AM -0500, Igor Pechtchanski wrote: Hi, all, FYI, I'm still working on the PPL, but doing it properly is taking more time than I anticipated. I now appreciate Dan's efforts even more... :-) The PPL *is* coming, just not as soon as I expected. IIRC, Dan will be back next week. He said hopefully in his e-mail to the naim list... In any case, the automated system was known to miss some messages, so a human eyeballing once in a while might be helpful, and the effort will not be wasted. Have I mentioned that Dan now works a few cubicles away from my office? cgf Yay, Dan! :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Ready for test coreutils-5.2.0-1
--- Mark Blackburn [EMAIL PROTECTED] wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: Ready for test coreutils-5.2.0-1
On Fri, 12 Mar 2004, Joshua Daniel Franklin wrote: --- Mark Blackburn marklistatfangorndotca wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) Not that simple, unfortunately. Anyone installing coreutils first and then installing the new version of cygutils (sans readlink) will have to reinstall coreutils to get readlink back... Maybe just putting a note in the announcement would suffice, but somehow I doubt it... BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and ^^ I believe the official name is sh-utils... textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Ready for test coreutils-5.2.0-1
On Fri, Mar 12, 2004 at 01:54:00PM -0500, Igor Pechtchanski wrote: textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Possibly but I would be surprised if it actually did anything. If this is actually working, please let me know and I'll add it to upset ASAP. cgf
Re: .rdata section in Cygwin executables?
On Friday 12 March 2004 15:51, Egor Duda wrote: Joe Buehler wrote: The emacs recompile fails because there is a section in the initially built emacs.exe named .rdata that the unexec() code for Cygwin is not expecting. The section appears to have something to do with exception handling and is only 1k in size. .rdata is a section where read-only data, such as constants, is stored. Most modern OSes and toolchain try to put as much info as possible to read-only segments of binary image because it reduce memory required by programs to run (when program is fork()ed, for instance, read-only pages may be shared between processes) In case of using gcc 3.3x and using auto-imported vars, you should use the '-fdata-sections' flags for compiling sources because otherwise these variables are not detected as variables. See http://sources.redhat.com/ml/binutils/2003-10/msg00256.html for more infos. Just a note. Ralf
Ready for test coreutils-5.2.0-1 [again]
Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. Package is available at the same location: http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2 http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2 832cd01fe909edb311f2c0d4ad258eb3 *coreutils-5.2.0-1-src.tar.bz2 70e3e652d47b8cd4c58a3fb4d9cd7432 *coreutils-5.2.0-1.tar.bz2 Mark Blackburn
Ready for test: patchutils 0.2.28
A long time ago, I packaged patchutils 0.2.26, uploaded them to personal webspace for testing, and... forgot to tell anyone about it. Oops! I've just updated to the latest upstream version (0.2.28). Packages are available here: Setup URL: http://centaur.robinson.cam.ac.uk/~mob22/cygwin Individual URLs: http://centaur.robinson.cam.ac.uk/~mob22/cygwin/cygdist/patchutils/patchutils-0.2.28-1.tar.bz2 http://centaur.robinson.cam.ac.uk/~mob22/cygwin/cygdist/patchutils/patchutils-0.2.28-1-src.tar.bz2 Please take a look at the packaging, and let me know if they are good to upload. Thanks, Max.
Re: Ready for test coreutils-5.2.0-1
Frédéric L. W. Meunier wrote: + /usr/lib/charset.alias I don't think this should be installed (neither by the current fileutils). Maybe Charles Wilson can comment. That's correct. /usr/lib/charset.alias SHOULD only be installed by the gettext package (since all the other projects which provide that file, get it by virtue of their local copy of the gettext sources). Unfortunately, fileutils, texinfo, and textutils all include it -- in addition to gettext. Sigh. -- Chuck
[GTG] Re: Ready for test: patchutils 0.2.28
On Fri, 12 Mar 2004, Max Bowsher wrote: A long time ago, I packaged patchutils 0.2.26, uploaded them to personal webspace for testing, and... forgot to tell anyone about it. Oops! I've just updated to the latest upstream version (0.2.28). Packages are available here: Setup URL: http://centaur.robinson.cam.ac.uk/~mob22/cygwin Individual URLs: http://centaur.robinson.cam.ac.uk/~mob22/cygwin/cygdist/patchutils/patchutils-0.2.28-1.tar.bz2 http://centaur.robinson.cam.ac.uk/~mob22/cygwin/cygdist/patchutils/patchutils-0.2.28-1-src.tar.bz2 Please take a look at the packaging, and let me know if they are good to upload. Thanks, Max. Max, Here's a quick look at packaging: everything looks fine -- the binaries work and are stripped, the directory structure is great, the sources build perfectly. There are four minor nits (below), but otherwise I'd say this is good to go. 1) The binary package contains an empty /etc/postinstall directory. 2) The original source tarball in the source package is executable. 3) When building, the link stage produces this message for each program: 'Info: resolving _optarg by linking to __imp__optarg (auto-import)'. 4) Giving the install option to the build script produces a message : Not found. (1) can be alleviated by using the CVS version of generic-build-script. I'm not certain, but I think (2) and (4) might be as well. (3) can be ignored, IMO. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Ready for test coreutils-5.2.0-1
On Thu, 11 Mar 2004, Mark Blackburn wrote: + /usr/lib/charset.alias I don't think this should be installed (neither by the current fileutils). Maybe Charles Wilson can comment. BTW, did you run make check ? Last time I tried it didn't run at all. -- http://www.pervalidus.net/contact.html
Re: Ready for test coreutils-5.2.0-1 [again]
Just now that 5.2.1 has been released ! On Fri, 12 Mar 2004, Mark Blackburn wrote: Here's what's changed since my last packaging attempt: 1) The following files are deleted from the distribution: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz 2) Fileutils patches have been included. -- http://www.pervalidus.net/contact.html
Re: Ready for test coreutils-5.2.0-1
Igor Pechtchanski wrote: On Fri, 12 Mar 2004, Joshua Daniel Franklin wrote: --- Mark Blackburn marklistatfangorndotca wrote: So I will delete the following: usr/bin/uptime.exe usr/bin/kill.exe usr/share/man/man1/uptime.1.gz usr/share/man/man1/kill.1.gz I will include the fileutils patches except the ones to src/copy.c and lib/regex.c since they have no apparent effect. One final question: for now do I rename usr/bin/readlink.exe to usr/bin/corereadlink.exe (ditto for [...]/man1/readlink.1.gz) or do I leave them as is? Leave it as-is and have it rely on Chuck's new cygutils without readlink. These packages, and the empty *utils ones, will have to all be uploaded at the same time to avoid installation issues. (There will probably be some anyway, users downloading and reinstalling old versions and wondering what happened. C'est la vie.) Not that simple, unfortunately. Anyone installing coreutils first and then installing the new version of cygutils (sans readlink) will have to reinstall coreutils to get readlink back... Maybe just putting a note in the announcement would suffice, but somehow I doubt it... BTW I have updated the setup.hint file: http://blackburn.homeip.net/cygwin-packages/release/coreutils/setup.hint sdesc: Basic file, shell and text manipulation utilities. ldesc: The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and ^^ I believe the official name is sh-utils... The project name is shellutils, the tarball is named sh-utils-MAJ.MIN.tar.gz see http://www.gnu.org/software/shellutils/shellutils.html Anyways I was just cutting and pasting from http://www.gnu.org/software/coreutils/ quote Introduction The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils http://www.gnu.org/software/fileutils/fileutils.html, shellutils http://www.gnu.org/software/shellutils/shellutils.html, and textutils http://www.gnu.org/software/textutils/textutils.html. Those three have been combined into a single set of utilities called the coreutils. /quote textutils. Those three have been combined into a single set of utilities called the coreutils. category: Base requires: cygwin libiconv2 libint ^^^ This is fine for testing, but don't forget to change it to include the empty obsoleted packages for the final version. Umm, doesn't setup's .ini parser support a Replaces: tag? Igor
RE: Solaris CDE 1.3 and cygwin
Hello, Thanks for your message but it doesn't work with me. My pointer still freezes and I have to kill the X window. I tried your command line: xinit -n xterm-1 -j -ls -sb -sl 500 -rightbar -geometry +361+0 -e bash -- -clipboard -scrollbars -engine 4 -ac -query server address -lesspointer -fp tcp/server address:7100 Here is the messages I obtain in the command window: $ xinit: connection to X server lost. Xterm: fatal IO error 104 (Connection reset by peer) or KillCient on X server :0.0 $ 4 [proc] xterm 3736 get_proc_lock: Couldn't aquire sync_proc_subproc for (2,0), Win32 error 288, last 2 Here is the XWin.log file: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.51 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X :0 -clipboard -scrollbars -engine 4 -ac -query tom -lesspointer -fp tcp/tom:7100 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1400 h 1050 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1400 dwHeight: 1050 winSetEngine - Using user's preference: 4 winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1400 h: 1050 winCreateBoundingWindowWindowed - Current w: 1400 h: 1050 winAdjustForAutoHide - Original WorkArea: 0 0 1022 1400 winAdjustForAutoHide - Adjusted WorkArea: 0 0 1022 1400 winCreateBoundingWindowWindowed - WindowClient w 1392 h 995 r 1392 l 0 b 995 t 0 winWindowProc - WM_SIZE - window w: 1400 h: 1022, new client area w: 1392 h: 995 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 5568 winAllocateFBShadowDDNL - Created shadow pitch: 5568 winAllocateFBShadowDDNL - Created shadow stride: 1392 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 040C (040c) (--) Using preset keyboard for French (Standard) (40c), type 4 Rules = xfree86 Model = pc105 Layout = fr Variant = (null) Options = (null) winPointerWarpCursor - Discarding first warp: 696 497 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winProcSetSelectionOwner - Clipboard not yet started, aborting. winProcSetSelectionOwner - Clipboard not yet started, aborting. _ Hello, I have solved it, don't know why, but it's working now. The new command part inserted is '-fp tcp/server address:7100' The command is as follows. xinit -n xterm-1 -j -ls -sb -sl 500 -rightbar -geometry +361+0 -e bash -- -clipboard -scrollbars -engine 4 -ac -query server address -lesspointer -fp tcp/server address:7100 Roman o From: Igor Pechtchanski pechtcha at cs dot nyu dot edu o To: FARGES Christophe cfarges at laas dot fr, Pach Roman (GS-EC/ESA4) * Roman dot Pach at de dot bosch dot com o Cc: cygwin-xfree at cygwin dot com, cygwin at cygwin dot com o Date: Thu, 11 Mar 2004 07:29:12 -0500 (EST) o Subject: Re: Solaris CDE 1.3 and cygwin o References: [EMAIL PROTECTED] o Reply-to: cygwin-xfree at cygwin dot com o Reply-to: cygwin-xfree at cygwin dot com Wrong list. Both of these queries should go to cygwin-xfree. I'm redirecting this. On Thu,
Garbled task-bar icon
Hi all, After the recent update to X startup icon change, I get garbled icon on the task-bar, task-tray and 'Toggle' window (window that shows up when Alt-Tab is pressed). It seems as though, 'simple X' icon and 'Black and white X' icon showing up with in the same frame. I've included the bitmap image of the garbled icons. Is there anyway to avoid this problem? FYI, following are my system setup, and also attached XWin.log if of any use. CYGWIN_NT-4.0 wbbrown 1.5.8s(0.110/4/2) 20040206 11:33:08 i686 unknown unknown C ygwin X-start-menu-icons 1.0.0-1OK X-startup-scripts 1.0.1-1OK XFree86-base4.3.0-1OK XFree86-bin 4.3.0-11 OK XFree86-etc 4.3.0-7OK XFree86-fenc4.2.0-3OK XFree86-fnts4.2.0-3OK XFree86-fscl4.2.0-3OK XFree86-lib 4.3.0-1OK XFree86-man 4.3.0-4OK XFree86-startup-scripts 4.3.0-1OK XFree86-xserv 4.3.0-54 OK Thanks in advance, Haro =--- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Kubota Graphics Technology Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] inline: start.bmpWelcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.54 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -clipboard -rootless -emulate3buttons 50 -lesspointer ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1152 h 864 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Returning, supported engines 0003 winScreenInit - dwWidth: 1152 dwHeight: 864 winSetEngine - Using Shadow DirectDraw winAdjustVideoModeShadowDD - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1152 h: 864 winCreateBoundingWindowWindowed - Current w: 1152 h: 864 winAdjustForAutoHide - Original WorkArea: 0 0 864 1152 winAdjustForAutoHide - Taskbar is auto hide winAdjustForAutoHide - Found BOTTOM auto-hide taskbar winAdjustForAutoHide - Adjusted WorkArea: 0 0 863 1152 winCreateBoundingWindowWindowed - WindowClient w 1152 h 863 r 1152 l 0 b 863 t 0 winCreateBoundingWindowWindowed - Returning winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowDD - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (II) Loading US keyboard layout. (--) winConfigKeyboard - Layout: e0200411 (0411) (--) Using preset keyboard for Japanese (411), type 7 Rules = xfree86 Model = jp Layout = jp Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! winPointerWarpCursor - Discarding first warp: 576 431 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
Questions on xhost, local display, etc.
You may remember a long thread about this around the new year, the specific issue then (trying to run the external xwinclip program) is no longer with us but since having to do a complete re-install due to a disk optimiser destroying the data on my disk I have a few things that still aren't quite clear for me. Is it possible to run any of the cygwin/X programs that require to display something other than in the console window without running a local X server of some sort? If it isn't possible with the default set up is there any workaround? It would be good for example to be able to run GUI editor windows (e.g. xvile for cygwin) without having to run an X desktop. I have looked back in the mailing list archives at the earlier thread and reminded myself how I eventually overcame the 'catch 22' problem of not being able to run xhost because it wanted permission to write on the display which needed xhost to run to allow it to. Is the /etc/X0.hosts file format described or documented anywhere? I looked for it in the documentation and couldn't find anything, it would be good to have this in the FAQ at least because it's a lifesaver! -- Chris Green ([EMAIL PROTECTED])
Re: Questions on xhost, local display, etc.
On Fri, 12 Mar 2004, Chris Green wrote: Is it possible to run any of the cygwin/X programs that require to display something other than in the console window without running a local X server of some sort? If it isn't possible with the default set up is there any workaround? It would be good for example to be able to run GUI editor windows (e.g. xvile for cygwin) without having to run an X desktop. Not really. gvim does such a thing. It has a fallback to tty if X11 is failing. But it must be prepared in the program. I have looked back in the mailing list archives at the earlier thread and reminded myself how I eventually overcame the 'catch 22' problem of not being able to run xhost because it wanted permission to write on the display which needed xhost to run to allow it to. Is the /etc/X0.hosts file format described or documented anywhere? It is referenced in man xhost. But the format is quite simple. One allowed host per line. it would be good to have this in the FAQ at least because it's a lifesaver! I will not put this to the faq since its a big security hole and should only be used if there is no other way. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: It works!
I'm taking this to the list so takuma and kesuke may comment it too.
On Fri, 12 Mar 2004, Alexander Gottwald wrote:
On Thu, 11 Mar 2004, Harold L Hunt II wrote:
http://msu.edu/~huntharo/xwin/devel/server/CygwinX-Accelerated-OpenGL-Support-20040311-2030.png
(24 KiB)
The only problem with it that I noticed was minor and obvious:
It allocates the OpenGL surface according to the properties of the
current window's parent, not the current window. So, the glxgears
program shows up in the xterm window instead of the glxgears window.
Also, if you run without multi-window and use twm, the OpenGL surface
will fill the entire root window (seems to be the same problem).
Interesting: if you move the xterm window in multi-window mode, the
surface moves with that window correctly :)
The GL rendering is bound to the devicecontext. The DC moves if you move
the window. In normal mode the GL rendering uses the whole xserver window
and draws the gears in the lower left corner. Clear sign of wrong DC size.
I currently use GetActiveWindow() to get a window handle. This surely
wrong. But attaching to the real window will require some functions
which get the hwnd from the pScreenPriv structure
What I need is a function
struct win_window_metrics
{
HWND hwnd;
RECT rect;
}
void win_get_window_metrics(WindowPtr winptr, win_window_metrics metrics)
{
if (multiwindow) {
metrics-hwnd = window_hwnd;
metrics-rect.left = 0;
metrics-rect.top = 0;
metrics-rect.right = window_width;
metrics-rect.bottom = window_height;
} else {
metrics-hwnd = global_hwnd;
metrics-rect.left = window_left;
metrics-rect.top = window_top;
metrics-rect.right = window_left + window_width;
metrics-rect.bottom = window_top + window_height;
}
}
If we already have a HRGN handle i could use that instead of the RECT.
I have to create a region anyway in GetDCEx(hwnd, hrgn, flags).
bye
ago
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
SNNS Problem
Hello, Some months ago, I sent a mail describing a problem with a SNNS popup dialog: http://sources.redhat.com/ml/cygwin-xfree/2004-01/msg00221.html I have looked inside the source code of SNNS, and I found that maybe the XawListChange(Widget w, String * list, int nitems, int longest, int resize) function is the source of the problem. This function is called by the ui_xAddListEntry function (ui_xWidget.c file in the xgui/source directory). I've tested the content of the parameters and they look OK. The widget seems to be correctly initialized (the popup is displayed correctly excepted the content of the list), the list contains nitems strings, longest is set to 0 and resize is set to True. What can I do to solve this problem ? Your sincerely, Yann COLLETTE
Re: It works!
On Thu, 11 Mar 2004, Harold L Hunt II wrote: Alexander, Nice work: http://msu.edu/~huntharo/xwin/devel/server/CygwinX-Accelerated-OpenGL-Support-20040311-2030.png (24 KiB) The only problem with it that I noticed was minor and obvious: It allocates the OpenGL surface according to the properties of the current window's parent, not the current window. So, the glxgears program shows up in the xterm window instead of the glxgears window. Also, if you run without multi-window and use twm, the OpenGL surface will fill the entire root window (seems to be the same problem). Interesting: if you move the xterm window in multi-window mode, the surface moves with that window correctly :) http://www-user.tu-chemnitz.de/~goal/xfree/glxgears.png - glxgears in the correct window :) - cygwin gvim with X11 support ;) (i doubt Corinna will ever enable this in the package) - ugly icon in taskbar :( bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: It works!
On Fri, 12 Mar 2004, Alexander Gottwald wrote: http://www-user.tu-chemnitz.de/~goal/xfree/glxgears.png Some numbers: taken on athlon 1800 with Matrox G550 Accelerated OpenGL from XWin-CVS [EMAIL PROTECTED]:~/pub/packages$ DISPLAY=cyghost:1.0 glxgears 5241 frames in 5.0 seconds = 1048.200 FPS 4453 frames in 5.0 seconds = 890.600 FPS 4316 frames in 5.0 seconds = 863.200 FPS 4476 frames in 5.0 seconds = 895.200 FPS Software OpenGL from XFree86-serv 4.3.0-54 [EMAIL PROTECTED]:~/pub/packages$ DISPLAY=cyghost:0.0 glxgears 1690 frames in 5.0 seconds = 338.000 FPS 1230 frames in 5.0 seconds = 246.000 FPS 1028 frames in 5.0 seconds = 205.600 FPS 1379 frames in 5.0 seconds = 275.800 FPS bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: X/Cygwin icon proposal
Hi Nahor, Alexander Gottwald wrote: It was (is) in CVS and I really like it. Even much better than the new one. Nahor [EMAIL PROTECTED] writes: Maybe one can add yet-another-option on the commandline and have several icons in the exe (or on a special library or whatever). Hm, is the full alpha channel independent of the 1-bit transparency mask that we have on older Windows version? If so, couldn't we combine both icons into one? On XP, the white background and black border would be hidden through the alpha mask. On older systems the white background would show. The only downside would be that the X character would have to be one pixel smaller on each side, because in the white-background version we need two borders, one white and one black. benny
Re: X/Cygwin icon proposal
Benjamin Riefenstahl wrote: Hm, is the full alpha channel independent of the 1-bit transparency mask that we have on older Windows version? If so, couldn't we combine both icons into one? On XP, the white background and black border would be hidden through the alpha mask. On older systems the white background would show. No, I don' think it would work. I don't know the details but right now, the icon is not a white square on older system. So somehow, windows put the transparent color where the alpha channel is fully transparent. Maybe I could hack it by not making the alpha channel fully transparent but near enough as to make no difference on XP. But that doesn't solve the issue of what people prefer: a square icon or a jagged one. Anyway the best is still the config file. People can then select the icon they want: black X on white square, black X with white border, X with edges at 45 degrees, fully black icon, blue X, red X, pig with wings, X on top of MS Windows logo... you name it. Nahor
Re: Garbled task-bar icon
[EMAIL PROTECTED] wrote: After the recent update to X startup icon change, I get garbled icon on the task-bar, task-tray and 'Toggle' window (window that shows up when Alt-Tab is pressed). Can you look at this icon, does it look garbled? Can you swith your screen resolution to 256 and 16 colors and see if they are garbled too? Nahor inline: x_test6.ico
Re: X/Cygwin icon proposal
Hi Nahor, Nahor [EMAIL PROTECTED] writes: No, I don' think it would work. I don't know the details but right now, the icon is not a white square on older system. Older systems use a 1-bit transparency mask (I forgot how this works in detail). I am pretty sure that this is a separate item from the alpha channel, because older systems couldn't interprete anything but this 1-bit format. OTOH, I guess that the tools that you use to create the icon don't allow to edit those two items separately. benny
Re: X/Cygwin icon proposal
Hi Alexander, Alexander Gottwald [EMAIL PROTECTED] writes: It was (is) in CVS and I really like it. Even much better than the new one. Thanks. I got it from CVS and noticed that the original version is in there. Harold had mentioned a bug with the 24x24 image and I had sent a new version later, see http://sources.redhat.com/ml/cygwin-xfree/2003-09/msg00270.html. benny
Re: XWin 4.3.0-50 crashes with -multiwindow
Fabrizio, [EMAIL PROTECTED] wrote: Harold, I installed your package, and it crashes as well with -multiwindow :( . Hmm... leads me to suspect some other problem on your system. I will investigate further, for example by rebuilding XWin from sources and running it through GDB. Another difference could be that I am using Windows 2000 and the screenshot seemed to be from Windows XP. It is usually a red herring to suspect the version of Windows has something to do with it. A debug version of XWin would be a good idea. Harold
Re: Garbled task-bar icon
I don't have any ideas. Jehan --- is the order of the icon formats within the icon file importatnt in some locales? Harold [EMAIL PROTECTED] wrote: Hi all, After the recent update to X startup icon change, I get garbled icon on the task-bar, task-tray and 'Toggle' window (window that shows up when Alt-Tab is pressed). It seems as though, 'simple X' icon and 'Black and white X' icon showing up with in the same frame. I've included the bitmap image of the garbled icons. Is there anyway to avoid this problem? FYI, following are my system setup, and also attached XWin.log if of any use. CYGWIN_NT-4.0 wbbrown 1.5.8s(0.110/4/2) 20040206 11:33:08 i686 unknown unknown C ygwin X-start-menu-icons 1.0.0-1OK X-startup-scripts 1.0.1-1OK XFree86-base4.3.0-1OK XFree86-bin 4.3.0-11 OK XFree86-etc 4.3.0-7OK XFree86-fenc4.2.0-3OK XFree86-fnts4.2.0-3OK XFree86-fscl4.2.0-3OK XFree86-lib 4.3.0-1OK XFree86-man 4.3.0-4OK XFree86-startup-scripts 4.3.0-1OK XFree86-xserv 4.3.0-54 OK Thanks in advance, Haro =--- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Kubota Graphics Technology Inc. /|\ |_| |_|_| 2-8-8 Shinjuku, Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: [EMAIL PROTECTED] Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.54 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -clipboard -rootless -emulate3buttons 50 -lesspointer ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1152 h 864 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Returning, supported engines 0003 winScreenInit - dwWidth: 1152 dwHeight: 864 winSetEngine - Using Shadow DirectDraw winAdjustVideoModeShadowDD - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1152 h: 864 winCreateBoundingWindowWindowed - Current w: 1152 h: 864 winAdjustForAutoHide - Original WorkArea: 0 0 864 1152 winAdjustForAutoHide - Taskbar is auto hide winAdjustForAutoHide - Found BOTTOM auto-hide taskbar winAdjustForAutoHide - Adjusted WorkArea: 0 0 863 1152 winCreateBoundingWindowWindowed - WindowClient w 1152 h 863 r 1152 l 0 b 863 t 0 winCreateBoundingWindowWindowed - Returning winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowDD - Masks f800 07e0 001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (II) Loading US keyboard layout. (--) winConfigKeyboard - Layout: e0200411 (0411) (--) Using preset keyboard for Japanese (411), type 7 Rules = xfree86 Model = jp Layout = jp Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/100dpi/, removing from list! winPointerWarpCursor - Discarding first warp: 576 431 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
Re: Fontpath and IPC problems when switching from XWin-44 to 54 under latest cygwin
On Fri, 12 Mar 2004, Dr. Volker Zell wrote: Hi all Because lack of time I tried switching from XWin-44 to XWin-54 today and got the following errors in my XWin.log which were not present in XWin-44 (see logfile below), 2 font paths could not be initialized and IPC support was disabled although cygip2 was running (as can be seen in the log file from XWin-44) I also had the XWin versions 47 and 49 handy, so I'm attaching also the their logfiles. As can be seen IPC support is not recognized anymore in 47 and the path initialization problems show up in 49. Any hints, cause I really need IPC support and don't want to sty behind with my XWin version. Just the obvious one here: http://cygwin.com/ml/cygwin-announce/2004-02/msg8.html IIRC, XWin has not been updated to use cygserver, or updated to use the new cygipc layout. So, it's probably a broken mix at the moment. I'll try to provide a patch to transition to cygserver later, time permitting. It should be fairly easy for anyone to try, though. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444
Re: Fontpath and IPC problems when switching from XWin-44 to 54 under latest cygwin
4.3.0-45 change log: # xc/lib/font/fontfile/dirfile.c, encparse.c, fontfile.c - Some more font path checks. (David Dawes) # xc/lib/font/fontfile/dirfile.c - Fix an exploitable buffer overflow. (Greg MacManus (iDEFENSE Labs)) That helps to explain at least part of it... but I don't understand why the paths were valid before but not valid now. Anyone care to look into this? As for the MIT-SHM support: the current build that I have in preparation for -55 properly enables/disables MIT-SHM support depending on whehter ipc-daemon2 is running or not. I can only assume that my build tree got messed up at some point. I did a complete rebuild yesterday so it might have fixed that bustage. Harold Dr. Volker Zell wrote: Hi all Because lack of time I tried switching from XWin-44 to XWin-54 today and got the following errors in my XWin.log which were not present in XWin-44 (see logfile below), 2 font paths could not be initialized and IPC support was disabled although cygip2 was running (as can be seen in the log file from XWin-44) I also had the XWin versions 47 and 49 handy, so I'm attaching also the their logfiles. As can be seen IPC support is not recognized anymore in 47 and the path initialization problems show up in 49. Any hints, cause I really need IPC support and don't want to sty behind with my XWin version. Ciao Volker
Re: x-start-menu-icons doesn't install on a W2K german OS
[Let's try this again, this time without passing on the false-positive from SpamAssassin] Volker, Dr. Volker Zell wrote: Hi see subject. Following is a dir listing (inclusive control-chars) from my Documents and Settings directory on a german W2K system. Had you ever installed the XFree86-bin-icons package? Did it work, or did it have the same problem? This looks like a code page problem (the ³ is an ü in the Windows codepage) Check the output of: cygpath -A -P That is how we get the path to that folder. Other than that, I had no ideas why bash would munge this... but my knowledge on this topic is not great. Anyone have some ideas? Harold
Re: x-start-menu-icons doesn't install on a W2K german OS
On Fri, 12 Mar 2004, Harold L Hunt II wrote: [Let's try this again, this time without passing on the false-positive from SpamAssassin] Volker, Dr. Volker Zell wrote: Hi see subject. Following is a dir listing (inclusive control-chars) from my Documents and Settings directory on a german W2K system. Had you ever installed the XFree86-bin-icons package? Did it work, or did it have the same problem? This looks like a code page problem (the ? is an u in the Windows codepage) Check the output of: cygpath -A -P That is how we get the path to that folder. Other than that, I had no ideas why bash would munge this... but my knowledge on this topic is not great. Anyone have some ideas? Harold This is probably an ASCII vs Unicode issue. Most of Cygwin calls the ASCII versions of the Windows API. I'm not sure Cygwin is even Unicode-aware. Windows uses Unicode internally to encode the filenames. Theoretically, Windows should do the right translation under the covers. It may be as simple as setting the correct codepage or locale before trying to create the path... Not running the localized version of Windows, I can't really investigate this. Volker, do you feel up to it? A simple 'ls -d `cygpath -A -P`' should expose the bug, and setting the right locale before this call may make it go away, in which case please report to the list what made it work... :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Cygwin X server crashes when a remote Xemacs is run
Hi, I still get this crash with the latest server (4.3.0-54). Unfortunately I am not able to access cvs repositories outside of our company's network, so I cannot build a debug version. I'd be happy to run a debug version that someone builds for me, or I can build it if the source could be tarred and placed on a website so I can download it. Thanks! Brian Quoting [EMAIL PROTECTED]: I'm willing. Brian Quoting Harold L Hunt II [EMAIL PROTECTED]: Anybody care to run a debug build of XWin.exe in gdb to find the crash location? Harold Brian R.Landy wrote: Hi, I see what appears to be the same crash (address 0x61093b2c), using Vim 6.2 with the GTK1 GUI. One remote system is running AIX, the other Solaris. The cygwin system runs NT 4 SP6. However, I only crash if I run XWin.exe -multiwindow. Switching to windowed, fullscreen, or even rootless causes the crash to go away. Nothing is written to Xwin.log after the normal startup messages. Brian Here what I'm trying to do: I establish a rsh connection with a UNIX/Linux machine and open an xterm. The I run Xemacs on this remote machine and XWin.exe crashes. I tried it connecting with both a Linux machine and a Alpha machine. Here the Xemacs versions installed on those machines: Linux - Xemacs 21.1 (patch 14) i386-redhat-linux Alpha - Xemacs 20.4 alpha-dec-osf3.2 Here the Windows error message: Exception: access violation (0xc005), Address: 0x61093b2c I'm running Cygwin 1.5.5-1 on Windows NT 4.0 Workstation. XWin.exe version is 4.3.0-20 Giampaolo Orrigo
Re: Garbled task-bar icon
Harold L Hunt II wrote: I don't have any ideas. Jehan --- is the order of the icon formats within the icon file importatnt in some locales? I have no idea. I would think not. But I would not be surprised if it uses a better icon (higher bit depth) if it can't find one that matches the screen bit depth. In this case 32b. Then, it doesn't expect the unused byte (used for the alpha channel now) to change value. Adding a 24 bits icons might solve it because it's the best fit for a 16bits screen that doesn't know about alpha channel. So I attached is a file with the 24b bit depth added. I also inverted the bit depth. It used to be 32b then 256 colors then 16. I moved the 16 first, then 256, then 24b, then 32b. That way, if Windows select the first icon that is good enough for the screen resolution, it will take the 24b first. Last, I used to have the high resolution first (32x32) and the low last (16x16). FireFox/Thunderbird have the low first, so I changed that too. In the end, I used to have: size then bit depth, from best to worst (32x32x32, 32x32x8, 32x32x4, 24x24x32, 24x24x8, ..., 16x16x4) Now, in the attached file, I have: bit depth then size, from worst to best (16x16x4, 24x24x4, 32x32x4, 16x16x8, 24x24x8, ..., 32x32x32) ...crossing fingers... Nahor inline: x_test8.ico
x-start-menu-icons doesn't install on a W2K german OS
Hi see subject. Following is a dir listing (inclusive control-chars) from my Documents and Settings directory on a german W2K system. 11:13 AM [513] pwd /c/Dokumente und Einstellungen/All Users [EMAIL PROTECTED] /c/Dokumente und Einstellungen/All Users 11:13 AM [514] ls -lat --show-control-chars total 0 drwxr-xr-x+ 9 root admin4096 Mar 12 10:59 ./ drwxrwxrwx+ 3 vzelladmin 0 Mar 12 10:59 Startmen³/ - got created by setup.exe drwxrwxr-x+ 7 root system 4096 Apr 13 2003 ../ drwxr-xr-x+ 2 root admin 0 Mar 31 2003 Desktop/ drwxr-xr-x+ 3 root admin4096 Feb 23 2003 Startmenü/ - This was there already drwxrwxrwx+ 2 root admin 0 May 29 2002 DRM/ drwxr-xr-x+ 4 root admin 0 Feb 24 2002 Dokumente/ drwxr-xr-x+ 3 root admin 0 Feb 5 2002 Anwendungsdaten/ drwxr-xr-x+ 2 root admin 0 Feb 5 2002 Vorlagen/ [EMAIL PROTECTED] /c/Dokumente und Einstellungen/All Users Here the relvant part from setup.log.full 2004/03/12 10:59:24 running: D:\\bin\sh.exe -c /etc/postinstall/fontconfig.sh 2004/03/12 10:59:27 running: D:\\bin\sh.exe -c /etc/postinstall/X-start-menu-icons.sh mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\bitmap.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\dpsexec.lnk failed; does the target directory exist? dpsexec:Display PostScript command interface:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Tools:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\dpsinfo.lnk failed; does the target directory exist? dpsinfo:The Display PostScript extension:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\editres.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\fc-list.lnk failed; does the target directory exist? fc-list:List available FreeType fonts:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Toys\glxgears.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\glxinfo.lnk failed; does the target directory exist? glxinfo:GLX information:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Toys\ico.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\oclock.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\showrgb.lnk failed; does the target directory exist? showrgb:List rgb database:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Games\texteroids.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\viewres.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\wmagnify.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xbiff.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xcalc.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xclock.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\xconsole.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\xcutsel.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xditview.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\xdpyinfo.lnk failed; does the target directory exist? xdpyinfo:Display information:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All
src/winsup/cygwin ChangeLog exceptions.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-03-12 08:22:23 Modified files: winsup/cygwin : ChangeLog exceptions.cc Log message: * exceptions.cc (sigpacket::process): Simplify code slightly. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2347r2=1.2348 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srcr1=1.212r2=1.213
winsup/mingw ChangeLog include/process.h
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2004-03-12 16:39:37 Modified files: mingw : ChangeLog mingw/include : process.h Log message: * include/process.h: Remove the #endif associated with removal of __STRICT_ANSI__ guard from non-ANSI header. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/mingw/ChangeLog.diff?cvsroot=uberbaumr1=1.178r2=1.179 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/mingw/include/process.h.diff?cvsroot=uberbaumr1=1.5r2=1.6
src/winsup/cygwin ChangeLog wait.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-03-12 22:03:33 Modified files: winsup/cygwin : ChangeLog wait.cc Log message: * wait.cc (wait4): Initialize pointer on entry. Avoid calling call_signal_handler twice since that guarantees exiting with errno set to EINTR. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2348r2=1.2349 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wait.cc.diff?cvsroot=srcr1=1.30r2=1.31
src/winsup/mingw ChangeLog include/malloc.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2004-03-13 01:03:31 Modified files: winsup/mingw : ChangeLog winsup/mingw/include: malloc.h Log message: * include/malloc.h: Remove __STRICT_ANSI__ guard. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.179r2=1.180 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/malloc.h.diff?cvsroot=srcr1=1.6r2=1.7
Patch for /proc/meminfo handler
With the Cygwin 1.5.7-1 DLL, 'cat /proc/meminfo' returns an incorrect
value for free swap space. This is most noticeable when the free virtual
memory is less than the total physical memory, in which case the
calculated free swap space is a negative value. This value is then
converted to an unsigned int for display purposes, resulting in a very
large positive number which is greater than the total amount of swap
space.
A patch to correct this problem is attached.
Regards
Andrew
fhandler_proc.cc.diff
--
Andrew Klopper[EMAIL PROTECTED]
Dimension Data PLCTel: +27-11-575-1424
Johannesburg, South AfricaFax: +27-11-576-1424
This email and all contents are subject to the following disclaimer:
http://www.didata.com/disclaimer.asp;
begin 666 fhandler_proc.cc.diff
M+2TM(9H86YD;5R7W!R;V,N8V,N;W)I9PDR,# S+3$Q+3(V(# T.C$U.C W
M+C P,3 P,# P, K,#(P, T**RLK(9H86YD;5R7W!R;V,N8V,),C P-TP
M,RTQ,2 Q-3HT,CHR,2XW,S$V,[EMAIL PROTECTED],# @*S R,# -D! (TS.3$L-R K,SDQ
M+#@0$ -B @(UE;5]T;W1A; ](UE;6]R5]S=%T=7,N9'=4;W1A;%!H
M7,[#0H@(!M96U?9G)E92 ](UE;6]R5]S=%T=7,N9'=!=F%I;%!H7,[
M#0H@(!S=V%P7W1O=%L(#T@;65M;W)Y7W-T871URYD=U1O=%L4%G949I
M;[EMAIL PROTECTED]]T86P[#0HM(!S=V%P7V9R964@/2!M96UOGE?W1A='5S
M+F1W079A:6Q086=E1FEL92 M(UE;5]T;W1A;#L-BL@('-W87!?9G)E92 ]
M(UE;6]R5]S=%T=7,N9'=!=F%I;%!A9V5:6QE(T@;65M7V9R964[#0H@
M(!R971U[EMAIL PROTECTED];6%L;%]S')I;G1F(AD97-T8G5F+ B( @( @( @
M=]T86PZ( @( @=7-E9#H@( @(!FF5E.EQN(@T*( D)0D@( B365M
M.B @)3$P;'4@)3$P;'4@)3$P;'5;B(-B )0D)( @(E-W87 Z(4Q,QU
1(4Q,QU(4Q,QU7XB#0H`
`
end
Re: [Patch] src/winsup/mingw/include/process.h __STRICT_ANSI__
On Thu, Mar 11, 2004 at 07:23:37PM -0500, Brian Keener wrote: I notice when trying to compile the #endif got left behind. Sure you found it by now. 2004-03-11 Brian Keener [EMAIL PROTECTED] * include/process.h: Remove the #endif associated with removal of __STRICT_ANSI__ guard from non-ANSI header. I've taken the libiberty of applying this patch since it is stalling my ability to generate a snapshot. I hope Danny won't mind. cgf
Re: cygutils - mkshortcut - Patch for --desc option for description/tooltip text - Needed for new Cygwin/X package
Joshua Daniel Franklin wrote: Looks good to me. I'd rather the --help output be kept under 80 chars, but it's already too late for the --workingdir option too. Oh well. okay... Before you release another cygutils package, note that 'readlink' may conflict with the proposed coreutils. Might be a good opportunity for coordination. Sure -- but I'm not going to delay cygutils-1.2.5 waiting for coreutils to finish shaking down. If I need to release cygutils-1.2.6 next week, I'll do so. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Xemacs Beta Build 21.5-b16
David == David A Cobb writes: David I tried to bring up the beta build of xemacs-21.5-b16 today and got David a bit of a surprise. David The gamma or mainline version: launching with $DISPLAY unset comes David up using MS Windows - as advertised. David The 21.5-b16, as Volker built it, with $DISPLAY unset, comes up in David non-windowing mode, i.e. it uses the rxvt terminal window. David Now, that's not really terrible. I prefer the graphical but this does David work. But even so, there is a glitch here. When I exit the Xemacs, David the rxvt session gets closed -- my whole login session is gone. This does not happen for me. Ciao Volker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Difference between just having cygwin1.dll and running under cygw in
-Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
GVIM
Hello all, Why is only VIM and not GVIM included with the Cygwin package? I'd love to use GVIM straight from a Cygwin install. Phil Crescioli [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Also 20040306 snapshot crashes in Win95
On 11 Mar 2004 14:37:33 Christopher Faylor wrote: I no longer have a Win95 or Win98 system to check this type of thing with so, the lowest common denominator of problem that *I* will be able to investigate is WinME. Sorry, but if you want this solved you'll probably have to solve it yourself. Have we to assume that Win9X will not be any longer supported?. It would be a pity, there are a lot of old machines around that can have a new life with cygwin. It is terrible to stop at version 1.5.5-1 because new software is not compatible with it because of the fnctl64 problem. I can try, using gdb, to determine where exactly the problem happens, but I don't have enough knowledge of cygwin1.dll nor of Win95 programming in order to solve the problem. Maybe with some help I can contribute in solving it. I hope that something can be done. Rodrigo Medina -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems running Jabberd v1.4.3 under cygwin v1.5.7 (or latest snapshot), and heap allocation error caused by fork()
On Fri, Mar 12, 2004 at 01:28:02AM -0500, Frank Seesink wrote: Basically, no, I haven't been able to reproduce it outside of Jabberd. Then again, I don't have a lot of custom source to compile/use. My simple test program (the one which loaded a DLL which in turn did a fork()) worked fine, but that was an uber-simple app. Jabberd fires up multiple threads/processes with more than one fork()/spawn_() call prior to reaching the dnsrv module where the final fork() breaks the camel's back as it were. For the record, this problem usually indicates the need to run 'rebaseall'. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GVIM
Crescioli, Phil Phil.Crescioli at gd-ais.com writes: Hello all, Why is only VIM and not GVIM included with the Cygwin package? I'd love to use GVIM straight from a Cygwin install. Phil Crescioli Phil.Crescioli at gd-ais.com I think it is because gvim for unix requires X11 while vim does not. I use and installed the gvim for windows and run it from with rxvt terminals in cygwin and it works fine. The only problem I had was that it would not orginally accept unix style pathnames (forward slashes). I had to put in an add on packaage to get the pathnames to work right. If you are interested I will look up what that package was. -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GVIM
On Mar 12 08:37, Crescioli, Phil wrote: Hello all, Why is only VIM and not GVIM included with the Cygwin package? I'd love to use GVIM straight from a Cygwin install. Then, why don't you just step forward as package maintainer for a Cygwin version of gvim? See http://cygwin.com/setup.html. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: GVIM
Thanks for the info. I currently have a standalone gvim that works fine on Win XP. For now I'm just curious. I have other pressing Cygwin things to dive into before the gvim thing, but when the time is right, I will gladly contribute to the gvim deal since I am a very content Cygwin user :) Phil Crescioli Software Engineer, Surface Navy Programs GENERAL DYNAMICS Advanced Information Systems [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 9:41 AM To: [EMAIL PROTECTED] Subject: Re: GVIM On Mar 12 08:37, Crescioli, Phil wrote: Hello all, Why is only VIM and not GVIM included with the Cygwin package? I'd love to use GVIM straight from a Cygwin install. Then, why don't you just step forward as package maintainer for a Cygwin version of gvim? See http://cygwin.com/setup.html. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
nfs-server re-exporting mapped network drives
The file nfs-server-2.2.47-2.README states: If you want your mount and NFS daemons to re-export mapped network drives, you will need to run them under an account other than Local System, and start both daemons with the '-r' option to enable re-exporting. I was able to install the daemons using the -r option with my usual login account (which also works for mapping network drives). However when I try to start them in the services gui I get an error stating the program terminated unexpectedly and the windows event log is no more helpful. I don't have a problem if I install/start the daemons without -r under the default LocalSystem rather than my own account. Is this a possible bug in the nfsd/mountd daemons or is it actually rejecting my account at start-time? (I get no complaints when I enter my uid/password+password.) If it it rejecting my account, what type of permissions do I need to be able to do this? cygcheck attached. Thanks, -gene Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Mar 12 10:07:21 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem Output from C:\cygwin\bin\id.exe (nontsec) UID: 17951(SMITED) GID: 10545(mkgroup-l-d) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 17951(SMITED) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `c:\Documents and Settings\SMITED' MAKE_MODE = `unix' PWD = `/var/log' USER = `SMITED' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\SMITED\Application Data' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `04J005' COMSPEC = `C:\WINNT\system32\cmd.exe' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\SMITED' HOSTNAME = `04J005' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\JSC0006D' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/var' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SHELL = `/bin/bash' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\SMITED\LOCALS~1\Temp' TERM = `xterm' TMP = `c:\DOCUME~1\SMITED\LOCALS~1\Temp' USERDOMAIN = `SEA' USERNAME = `SMITED' USERPROFILE = `C:\Documents and Settings\SMITED' WINDIR = `C:\WINNT' WINDOWID = `168047280' _ = `/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
RE: nfs-server re-exporting mapped network drives
-Original Message- From: cygwin-owner On Behalf Of Smith, Gene Sent: 12 March 2004 15:38 The file nfs-server-2.2.47-2.README states: If you want your mount and NFS daemons to re-export mapped network drives, you will need to run them under an account other than Local System, and start both daemons with the '-r' option to enable re-exporting. I was able to install the daemons using the -r option with my usual login account (which also works for mapping network drives). However when I try to start them in the services gui I get an error stating the program terminated unexpectedly and the windows event log is no more helpful. I don't have a problem if I install/start the daemons without -r under the default LocalSystem rather than my own account. Is this a possible bug in the nfsd/mountd daemons or is it actually rejecting my account at start-time? (I get no complaints when I enter my uid/password+password.) If it it rejecting my account, what type of permissions do I need to be able to do this? cygcheck attached. Thanks, -gene It's most likely that the programs are actually starting OK but erroring out almost at once. You haven't tried the obvious experiments yet: what happens when you install them *with* -r under LocalSystem? What happens when you install them *without* -r under your usual login account? You've changed two things at one time: the command line flags, and the account under which it runs. You'll have to revert one of them to find out which of them caused the problem. Having said that, it's likely to be a Win ACL/privs problem. If you edit your local security policy to enable auditing of failures for all events, you may well get some useful information in your event viewer (security log) next time you try and start the server. It will certainly show up if the daemons are trying something that requires privileges enabled that they don't have. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
New News: === I have updated the version of rebase to 2.3-1. The tarballs should be available on a Cygwin mirror near you shortly. The notable changes since the previous release are: 1. enhance rebaseall to support a -T option which allows users to specify additional DLLs to rebase 2. comply with FHS directory structure The following are two examples of how to use rebaseall's -T option: 1. specify additional DLLs via a temp file: $ find /some/path -name '*.dll' /tmp/dll.list $ rebaseall -T /tmp/dll.list 2. specify additional DLLs via stdin: $ find /some/path -name '*.dll' | rebaseall -T - Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING The Cygwin rebase package contains two utilities, rebase and rebaseall. The first utility is modeled after Microsoft's SDK rebase: http://msdn.microsoft.com/library/en-us/tools/perfutil_2z39.asp The rebaseall utility is a convenient way for users that suffer from the Cygwin rebase problem to rebase their entire system (i.e., all of their DLLs). Note that rebaseall is only a stop-gap measure. Eventually the rebase functionality will be added to Cygwin's setup.exe, so that rebasing will happen automatically. Please read the README file: /usr/share/doc/Cygwin/rebase-2.3.README since it covers requirements, usage, known issues, etc. I would like to thank Ralf Habacker for providing the imagehelper library. This library has enabled me to create a rebase utility that is usable by all Cygwin user (regardless of platform) on all DLLs (regardless of stripping). 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. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. The setup.exe program will figure out what needs to be updated on your system and will install newer packages automatically. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. *** 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: [EMAIL PROTECTED] Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
-Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Missing /include/sys/stropts.h?
I am trying to compile SWI-Prolog under CygWin and am receiving a
message that stropts.h is missing from /include/sys. I checked and
there is no such file there or in any directory off of root or in the
CVS source tree. I placed a bug report with SWI-Prolog and received the
following response:
Hmm. This is part of the code to attach an xterm window to
a background thread for the multi-threaded version, which is
supposed to work if grantpt() exists (indicating there is
support for pseudo terminals) and multi-threading support.
[rest of bug response removed...]
I can see from the configure script that grantpt() exists...
Should the file stropts.h exist on CygWin? If not - could I copy it
from a Unix system (such as a MAC BSD (OS X)) and put it in CygWin?
Here is my cygcheck -s -v -r:
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Mar 12 07:52:11 2004
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Personal Communications
c:\Program Files\Common Files\Adaptec Shared\System
c:\Program Files\Personal Communications\
c:\Program Files\Microsoft SQL Server\80\Tools\BINN
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11530(SLEGRAND) GID: 10513(Domain Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11530(SLEGRAND) GID: 10513(Domain Users)
0(root)544(Administrators)
545(Users) 1009(OLAP Administrators)
12384(DC_INTRANET) 12238(DCORP_ADMIN)
10513(Domain Users)11531(ecomm)
13171(FS5_USER)13769(IT Group)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\SLEGRAND'
MAKE_MODE = `unix'
PWD = `/home/SLEGRAND'
USER = `SLEGRAND'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\slegrand\Application Data'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `SANJZF8241'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVSROOT = `:pserver:[EMAIL PROTECTED]:/cvs/src'
CVS_RSH = `/bin/ssh'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\slegrand'
HOSTNAME = `SANJZF8241'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\SANCDC012'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/X11R6/man:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/SLEGRAND/src/winsup/cygwin/include/sys'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PCOMM_ROOT = `C:\Program Files\Personal Communications\'
PKG_CONFIG_PATH = `:/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\slegrand\LOCALS~1\Temp'
TERM = `cygwin'
TEXMF = `{/usr/share/lilypond/2.0.1,/usr/share/texmf}'
TMP = `c:\DOCUME~1\slegrand\LOCALS~1\Temp'
USERDNSDOMAIN = `ICWPDC-SD.ICWGRP.COM'
USERDOMAIN = `ICWPDC-SD'
USERNAME = `SLEGRAND'
USERPROFILE = `C:\Documents and Settings\slegrand'
WINDIR = `C:\WINDOWS'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin/bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts
v2\/usr/X11R6/lib/X11/fonts
(default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
a: fd N/AN/A
c: hd NTFS 38138Mb 18% CP CS UN PA FC SLegrand
d: cd N/AN/A
C:\cygwin / system
binmode
C:\cygwin/bin /usr/bin system
binmode
C:\cygwin/lib /usr/lib system
binmode
C:\cygwin\usr\X11R6\lib\X11\fonts
Missing /include/sys/stropts.h?
That of course should have been /usr/include/sys :( = Shawn Legrand Carpe Noctem! Carpe Diem! Hieros Gamos! [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
Following up a thread in comp.lang.python... * Jason Tishler (2004-03-12 17:00 +0100) Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING This warning is in my not native english speaking opinion to be misinterpreted. I understood it as only when you *really* know what you're doing, use 'rebaseall' (and in all other cases 'rebase'...) but you probably meant use only 'rebaseall' (and not rebase) unless... Thorsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK Okay, I'll bite. I demand that you really mean to sound tough? ;-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
TCLTK:Re: couldn't load library ../libitcl32.a:invalid argument ...
On Wed, Mar 10, 2004 at 09:22:21AM +, Christian Montanari wrote: Hi, Any updates on this issue on package tcltk-20030901-1 ? Redhat stuff seems to work better (ie. like with the snavigator package). what is the difference with this installation ? replying to my own-self, to whom it concerns... I carried a little research and I have found a few calls for this long running problem with package tcltk-20030901-1 and earliers. Back in March 2003 there was an answer on GMANE.CYGWYN.DEBUG.INSIGHT, but not really making sense to me. I then debugged wish84g.exe, and found that libitcl32.a is an archives (!arch), therefore can not be loaded as DLL using TclpDlopen,[EMAIL PROTECTED] (found in tclload.c), then it come to light that the tcltk package must be constructed with: ./configure --enable-shared --enable-load; make all install and finally a little: cd /usr/local/lib; ln -s ../bin/*.dll . It did the trick: now I can use iwidget, itcl, and others... I am sure someone, somewhere knew it before me (sigh). I do not know how to update packages or submit patches, so, I leave the info there. Chao, Christian Montanari. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
-Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: 12 March 2004 16:54 To: Dave Korn Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1 On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK Okay, I'll bite. Consider yourself trolled! g I demand that you really mean to sound tough? ;-) Igor I Don't Think You Really Meant To Say That! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
I didn't Think You Really Meant To Say That. But I think he meant exactly what he said - If you *DON'T* *REALLY* know what you're doing, only use rebaseall. If you do know the implications (or you've been told to by One Who Knows), then you can use rebase, but still be careful. -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: 12 March 2004 16:54 To: Dave Korn Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1 On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK Okay, I'll bite. I demand that you really mean to sound tough? ;-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ This e-mail transmission is strictly confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information and if you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this email in error, please reply to the sender as soon as possible and delete the message. Please note that we are able to, and reserve the right to, monitor e-mail communications passing through our network. The views expressed in this email are not that of the company unless specified within the message. The inclusion of this footnote indicates that the mail message and any attachments have been checked for the presence of known viruses. If you have any comments regarding our policy please direct them to [EMAIL PROTECTED] This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Missing /include/sys/stropts.h?
-Original Message- From: cygwin-owner On Behalf Of Shawn Legrand Sent: 12 March 2004 16:08 Should the file stropts.h exist on CygWin? You already answered that one yourself: I checked and there is no such file there or in any directory off of root or in the CVS source tree. Anyway, you also asked: If not - could I copy it from a Unix system (such as a MAC BSD (OS X)) and put it in CygWin? That kind of game almost never works. Sure, the initial compilation will succeed, or at least it won't error out with a missing file, but since whatever library functions or OS features the header file describes don't actually exist on your system, it isn't going to help any: it'll probably all fall apart at the final link stage. BTW and FYI, here's the generic recipe for figuring out the answer to these sorts of question: stropts.h (a moment's googling shows me) is related to POSIX streams functionality. By searching for the keyword streams in the Posix spec at http://www.opengroup.org/onlinepubs/007904975/nframe.html I found a few of the functions involved were fattach, fdetach, putmsg, putpmsg. By searching in the cygwin api reference at http://cygwin.com/cygwin-api/cygwin-api.html I couldn't find any of those functions. So my deduction is that the POSIX streams functionality isn't implemented by cygwin and therefore it's no surprise the header isn't there. This also means that the program you are trying to compile depends on OS functionality that cygwin doesn't provide, and so porting it to cygwin will never be a simple configure'n'make. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: GVIM
Phil Crescioli wrote: [...] For now I'm just curious. I have other pressing Cygwin things to dive into before the gvim thing, but when the time is right, I will gladly contribute to the gvim deal since I am a very content Cygwin user :) It's been a while since I've done it, but gvim used to build pretty well out of the box for Cygwin. The catch (at least it was a catch at the time) was that it was the X11 version. For a while I maintained five flavors of VIM executables: Cygwin's official VIM, an X11 GVIM (really just a link), an X11-aware VIM, a Windows VIM, and a Windows GVIM. Today I use the Windows version of GVIM and the official Cygwin non-GUI version of VIM. However, since I last built gvim for Cygwin, the Win32 native X11 window manager has been added to Cygwin, and handling for paths from outside of Cygwin has been improved (e.g., \cygwin\bin\vim \autoexec.bat from a Command Prompt). So it might be worth reinvestigating. But perhaps what you really want isn't the X11 version at all, but a Cygwin version with a Windows interface. This might be preferable to reduce the interdepencies that otherwise could arise, since gvim is normally just the equivalent of vim -g (i.e., Would regular Cygwin VIM have to become X-aware? Would there be two separate programs called vim? etc.). Just some food for the curious. :-) -Jerry -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Missing /include/sys/stropts.h? [gold star alert]
On Fri, Mar 12, 2004 at 05:19:35PM -, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Shawn Legrand Sent: 12 March 2004 16:08 Should the file stropts.h exist on CygWin? You already answered that one yourself: I checked and there is no such file there or in any directory off of root or in the CVS source tree. Anyway, you also asked: If not - could I copy it from a Unix system (such as a MAC BSD (OS X)) and put it in CygWin? That kind of game almost never works. Sure, the initial compilation will succeed, or at least it won't error out with a missing file, but since whatever library functions or OS features the header file describes don't actually exist on your system, it isn't going to help any: it'll probably all fall apart at the final link stage. BTW and FYI, here's the generic recipe for figuring out the answer to these sorts of question: stropts.h (a moment's googling shows me) is related to POSIX streams functionality. By searching for the keyword streams in the Posix spec at http://www.opengroup.org/onlinepubs/007904975/nframe.html I found a few of the functions involved were fattach, fdetach, putmsg, putpmsg. By searching in the cygwin api reference at http://cygwin.com/cygwin-api/cygwin-api.html I couldn't find any of those functions. So my deduction is that the POSIX streams functionality isn't implemented by cygwin and therefore it's no surprise the header isn't there. This also means that the program you are trying to compile depends on OS functionality that cygwin doesn't provide, and so porting it to cygwin will never be a simple configure'n'make. Can we get a gold star over here for exemplary use of reasoning powers? Thank you, Dave, for explaining how to think about problems like this. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Missing /include/sys/stropts.h? [gold star alert]
On Fri, 12 Mar 2004, Christopher Faylor wrote: On Fri, Mar 12, 2004 at 05:19:35PM -, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Shawn Legrand Sent: 12 March 2004 16:08 Should the file stropts.h exist on CygWin? You already answered that one yourself: I checked and there is no such file there or in any directory off of root or in the CVS source tree. Anyway, you also asked: If not - could I copy it from a Unix system (such as a MAC BSD (OS X)) and put it in CygWin? That kind of game almost never works. Sure, the initial compilation will succeed, or at least it won't error out with a missing file, but since whatever library functions or OS features the header file describes don't actually exist on your system, it isn't going to help any: it'll probably all fall apart at the final link stage. BTW and FYI, here's the generic recipe for figuring out the answer to these sorts of question: stropts.h (a moment's googling shows me) is related to POSIX streams functionality. By searching for the keyword streams in the Posix spec at http://www.opengroup.org/onlinepubs/007904975/nframe.html I found a few of the functions involved were fattach, fdetach, putmsg, putpmsg. By searching in the cygwin api reference at http://cygwin.com/cygwin-api/cygwin-api.html I couldn't find any of those functions. So my deduction is that the POSIX streams functionality isn't implemented by cygwin and therefore it's no surprise the header isn't there. This also means that the program you are trying to compile depends on OS functionality that cygwin doesn't provide, and so porting it to cygwin will never be a simple configure'n'make. Can we get a gold star over here for exemplary use of reasoning powers? Thank you, Dave, for explaining how to think about problems like this. cgf We sure can. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: 12 March 2004 16:54 To: Dave Korn Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1 On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK Okay, I'll bite. Consider yourself trolled! g Fine. I'm on a diet anyway... :-D I demand that you really mean to sound tough? ;-) Igor I Don't Think You Really Meant To Say That! Oh. Like a milder version of http://cygwin.com/acronyms/#YOWTWYWT... :-) Worth adding to the OLOCA, you think?.. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: binutils-20040312-1
I've made a new version of binutils available for installation. This version is a refresh from CVS on sources.redhat.com. Binutils undergoes active development so there have been a number of fixes, many related to windows. If you have been experiencing problems with programs like dlltool, ld, objcopy, etc., it would be worthwhile to update your installation. 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Christopher Faylor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
-Original Message- From: Igor Pechtchanski Sent: 12 March 2004 18:43 On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: Igor Pechtchanski Sent: 12 March 2004 16:54 To: Dave Korn Subject: RE: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1 On Fri, 12 Mar 2004, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Jason Tishler Old News: === WARNING It is *strongly* recommended that users only use rebaseall unless they *really* know what they are doing or are instructed by one of the Cygwin developers. /WARNING IDTYRMTST :-) cheers, DaveK Okay, I'll bite. Consider yourself trolled! g Fine. I'm on a diet anyway... :-D I demand that you really mean to sound tough? ;-) Igor I Don't Think You Really Meant To Say That! Oh. Like a milder version of http://cygwin.com/acronyms/#YOWTWYWT... :-) Worth adding to the OLOCA, you think?.. Igor Dunno. I was gonna say Well, it's hardly cyg-specific, because I had the impression it was in common use, backed up by the fact that Bill Hughes has obviously heard it before. But when I did a quick google, it doesn't seem to be that widespread after all. Like two uses in the last six years on usenet and none on the web. http://groups.google.com/groups?q=idtymtsthl=enlr=ie=UTF-8oe=UTF-8sa=N; tab=wg I can't beleive that's not a false negative of some sort, but searching for the whole unabbreviated phrase doesn't do any better, so yeh, chuck it in! Heh. YOWTWYWT is even better though, because of the way it's pronounced! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Ny e-post adresse
Jeg vil ikke være på kontoret fra og med 01.01.2004 og vil ikke være tilbake før 18.08.2004. Min nye adresse er: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
CYGWIN 1.5.7: rmdir of cwd with open file crashes process
Hi.
Problem: If an attempt is made to rmdir the currwnt working directory when a
file is open in that irectory, the process will apparantly crash!
This was first noticed in Perl, with the following simple test case always
exiting with status 128
use File::Temp;
my $dir=tempdir(CLEANUP=1);
chdir $dir
open(FH,,testfile);
return 0;
Futher tests in C reveal that rmdir crashes internally
The attached C code tests the following 3 scenarios
1rmdir of the current working directory
rmdir succeeds, directory removed
2rmdir of a directory which is NOT current working directory when there
is a file open in the that directory:
rmdir returns error status 'Directory not empty'
3rmdir of the current working directory when there is a file open in
that directory:
** rmdir crashes internally !
--
$ uname -a
CYGWIN_NT-5.1 nielspc 1.5.7(0.109/3/2) 2004-01-30 19:32 i686 unknown unknown
Cygwin
Output of cygcheck -r -s -v attached as cygwin.out
begin 666 cygwin.out
M#0I#6=W:[EMAIL PROTECTED]@0V]N9FEG=7)A=EO;B!$:6%G;F]S=ECPT*
M0W5RF5N=!3[EMAIL PROTECTED][EMAIL PROTECTED])I($UAB Q,B R,#HP.3HP- R,# T
M#0H-E=I;F1O=W,@6% @2]M92!%9ET:6]N(%9EB [EMAIL PROTECTED];0@,C8P
M,!397)V:6-E(%!A8VL@,[EMAIL PROTECTED]6=W:6Y=7-R7QO8V%L
M7)I;@T*4,Z7-Y9W=I;EQB:6X-@E#.EQC6=W:6Y8FEN#0H)0SI8WEG
M=VEN7'5SEQ8,3%2-EQB:6X-@EC.EQ724Y$3U=37'-YW1E;3,R#0H)8SI
M5TE.1$]74PT*6,Z7%=)3D1/5U-4WES=5M,S)5V)E;0T*2)##0H)0SI
M8WEG=VEN7%!R;[EMAIL PROTECTED]2'5M;6EN9V)IF10V]N;F5C=EV:71Y
M7#N,#!06-C97-S;W)I97-(@T*#0I/[EMAIL PROTECTED])O;2!#.EQC6=W:6Y
M8FEN7ED+F5X92 H;F]N='-E8RD-E5)1#H@,3 P,RAM87)K=VEC;[EMAIL PROTECTED]
M.B U,3,H3F]N92D-C4Q,RA.;VYE*0T*#0I/[EMAIL PROTECTED])O;2!#.EQC6=W
M:6Y8FEN7ED+F5X92 H;G1S96,I#0I5240Z(#$P,#,H;6%R:W=I8VXI($=)
[EMAIL PROTECTED];F4I#0HP*')O;W0I( @( @( @( @( U,3,H3F]N92D@
M( @( @( @( -C4T-A!9UI;FES=')A=]RRD@(#4T-2A5V5RRD-
M@T*4WES1ER.B!#.EQ724Y$3U=37%-YW1E;3,R#0I7:6Y$:7(Z($,Z7%=)
M3D1/5U,-@T*2$]-12 ](!D.EQC6=W:6YH;VUE7UAFMW:6-N)PT*34%+
M15]-3T1%([EMAIL PROTECTED]'5N:[EMAIL PROTECTED]@/[EMAIL
PROTECTED];64O;6%R:W=I8VXG#0I54T52
M([EMAIL PROTECTED]UAFMW:6-N)PT*#0I!3$Q54T524U!23T9)3$4@/[EMAIL PROTECTED]1]C=6UE
M;G1S(%N9!3971T:6YGUQ!;[EMAIL PROTECTED]G,G#0I!4%!$051!([EMAIL PROTECTED],Z7$1O
M8W5M96YTR!A;[EMAIL PROTECTED]EN9W-3W=N97)07!P;EC871I;[EMAIL PROTECTED]%T82-
MD-,245.5$Y!344@/[EMAIL PROTECTED]V]L92-D-/34U/3E!23T=204U24Q%4R ]
M(!#.EQ0F]GF%M($9I;5S7$-O;6UO;B!:6QER-D-/35!55$523D%-
M12 ](!.245,4U!#)PT*0T]-4U!%0R ](!#.EQ724Y$3U=37'-YW1E;3,R
M7-M9YE4G#0I#5E-?4E-(([EMAIL PROTECTED]]B:6XOW-H)PT*1$E34$Q!62 ](!L
M;V-A;AOW0Z,-DA/345$4DE612 ](!#.B-DA/3450051(([EMAIL PROTECTED]
M;V-U;65N=',@86YD(%-E='1I;F=S7$]W;F5R)PT*2$]35$Y!344@/2!@;FEE
M;'-P8R-DE.1D]0051(([EMAIL PROTECTED]]UW(O;]C86PO:6YF;SHO=7-R+VEN9F\Z
M+W5SB]S:%R92]I;F9O.B]UW(O875T;W1O;VPO95V96PO:6YF;SHO=7-R
M+V%U=]T;V]L+W-T86)L92]I;F9O.B-DQ/1T].4T525D52([EMAIL PROTECTED]3DE%
M3%-00R-DU!3E!!5$@@/[EMAIL PROTECTED]B]L;V-A;]M86XZ+W5SB]M86XZ+W5S
MB]S:%R92]M86XZ+W5SB]A=71O=]O;]D979E;]M86XZ.B]UW(O6#$Q
M4C8O;6%N.B]UW(OW-L+VUA;B-DY534)%4E]/1E]04D]#15-33U)3(#T@
M8#(G#0I/3$105T0@/[EMAIL PROTECTED]B]B:6XG#0I/4R ](!7:6YD;W=S7TY4)PT*
M4$%'15(@/2!@;5SR MB-E!!5$A%6%0@/[EMAIL PROTECTED]/33LN15A%.RY050[
M+D--1#LN5D)3.RY60D4[+DI3.RY*4T4[+E=31CLN5U-()PT*4%)/0T534T]2
M7T%20TA)5$5#5%5212 ](!X.#8G#0I04D]#15-33U)?241%3E1)1DE%4B ]
M([EMAIL PROTECTED]:6QY(#$U($UO95L(#(@4W1E'!I;F@[EMAIL PROTECTED]
M=5L)PT*4%)/0T534T]27TQ%5D5,([EMAIL PROTECTED])PT*4%)/0T534T]27U)%5DE3
M24].([EMAIL PROTECTED] R,#4G#0I04D]'4D%-1DE,15,@/[EMAIL PROTECTED]4')O9W)A;2!:6QE
MR-E!23TU05 ]( D41')PT*4%,Q([EMAIL PROTECTED];7# S,UTP.UQW7# P-PT*
M7# S,ULS,FU75QU0%QH(%Q;7# S,ULS,VU=UPP,S-;,U70T*) G#0I3
M15-324].3D%-12 ](!#;VYS;VQE)PT*4TA,5DP@/2!@,2-E-94U1%3412
M259%([EMAIL PROTECTED],Z)PT*4UE35$5-4D]/5 ](!#.EQ724Y$3U=3)PT*5$5-4 ]
M(!C.EQ$3T-5345^,5Q/=VYEEQ,3T-!3%-^,5Q496UP)PT*5$5232 ](!C
M6=W:6XG#0I435 @/[EMAIL PROTECTED]1$]#54U%?C%3W=N97)3$]#04Q3?C%55M
M-E1:([EMAIL PROTECTED]TQ0T535TR+$TS+C4N,\P,CHP,#HP,Q-,3 N-2XP
M+S S.C P.C P)PT*55-%4D1/34%)3B ](!.245,4U!#)PT*55-%4DY!344@
M/[EMAIL PROTECTED](G#0I54T524%)/1DE,12 ](!#.EQ$;V-U;65N=',@86YD(%-E
M='1I;F=S7$]W;F5R)PT*5TE.1$E2([EMAIL PROTECTED],Z7%=)3D1/5U,G#0I?([EMAIL PROTECTED]]U
MW(O8FEN+V-Y9V-H96-K)PT*#0I(2T597T-54E)%3E1?55-%4EQ3;V9T=V%R
M95Q#6=N=7,@4V]L=71I;VYS#0I(2T597T-54E)%3E1?55-%4EQ3;V9T=V%R
M95Q#6=N=7,@4V]L=71I;VYS7$-Y9W=I;@T*2$M%65]#55)214Y47U5315)
M4V]F='=AF50WEG;G5S(%-O;'5T:6]NUQ#6=W:6Y;6]U;G1S('8R#0I(
M2T597T-54E)%3E1?55-%4EQ3;V9T=V%R95Q#6=N=7,@4V]L=71I;VYS7$-Y
M9W=I;EQ0F]GF%M($]P=EO;G,-DA+15E?0U524D5.5%]54T527%-O9G1W
M87)E7$-Y9VYUR!3;VQU=EO;G-0UE'5TE.+D1,3!S971U T*2$M%65]#
M55)214Y47U5315)4V]F='=AF50WEG;G5S(%-O;'5T:6]NUQ#64=724XN
M1$Q,('-E='5P7(Q-2XP#0I(2T597T-54E)%3E1?55-%4EQ3;V9T=V%R95Q#
M6=N=7,@4V]L=71I;VYS7$-91U=)3BY$3$P@V5T=7!8C$U+C!;6]U;G1S
M#0I(2T597T-54E)%3E1?55-%4EQ3;V9T=V%R95Q#6=N=7,@4V]L=71I;VYS
M7$-91U=)3BY$3$P@V5T=7!8C$U+C!;6]U;G1S7# P#0H@(AD969A=6QT
M*2 ](!#.B-B @=6YI ](
Subshell
#/bin/bash echo Silly ( sleep 50 ( sleep 50 ) ) wait each subshell is sh.exe. I want to be be bash.exe. How do I force that without having to write bash -c Thanks, Greg P.S. Looked at cygwin faq, archive, didn't find the answer although this I would think has been brought up before. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Subshell
On Fri, Mar 12, 2004 at 01:49:27PM -0600, Gregory Borota wrote: #/bin/bash echo Silly ( sleep 50 ( sleep 50 ) ) wait each subshell is sh.exe. Why would bash arbitrarily choose sh.exe as the subshell? I want to be be bash.exe. How do I force that without having to write bash -c P.S. Looked at cygwin faq, archive, didn't find the answer although this I would think has been brought up before. Hmm. c:\cd cygwin\bin c:\cygwin\binren sh.exe sh-saf.exe C:\cygwin\bin\sh.exe - C:\cygwin\bin\sh-saf.exe 1 file renamed c:\cygwin\binbash bash-2.05b$ (sleep 1)# works bash-2.05b$ cat /tmp/tst #!/bin/bash echo Silly (sleep 1 (sleep 1)) bash-2.05b$ /tmp/tst Silly bash-2.05b$ # works If bash used /bin/sh then it would have complained when running the above. I verified via strace that bash wasn't looking for sh.exe and settling for bash.exe if it didn't exist, too. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Smith, Gene Sent: 12 March 2004 15:38 The file nfs-server-2.2.47-2.README states: If you want your mount and NFS daemons to re-export mapped network drives, you will need to run them under an account other than Local System, and start both daemons with the '-r' option to enable re-exporting. I was able to install the daemons using the -r option with my usual login account (which also works for mapping network drives). However when I try to start them in the services gui I get an error stating the program terminated unexpectedly and the windows event log is no more helpful. I don't have a problem if I install/start the daemons without -r under the default LocalSystem rather than my own account. Is this a possible bug in the nfsd/mountd daemons or is it actually rejecting my account at start-time? (I get no complaints when I enter my uid/password+password.) If it it rejecting my account, what type of permissions do I need to be able to do this? cygcheck attached. Thanks, -gene It's most likely that the programs are actually starting OK but erroring out almost at once. You haven't tried the obvious experiments yet: what happens when you install them *with* -r under LocalSystem? What happens when you install them *without* -r under your usual login account? You've changed two things at one time: the command line flags, and the account under which it runs. You'll have to revert one of them to find out which of them caused the problem. Having said that, it's likely to be a Win ACL/privs problem. If you edit your local security policy to enable auditing of failures for all events, you may well get some useful information in your event viewer (security log) next time you try and start the server. It will certainly show up if the daemons are trying something that requires privileges enabled that they don't have. cheers, DaveK When I do -r with LocalSystem, all daemons start and I can mount as expected on remote computer, but can't see the mapped drive (which I have mounted on the computer running nfs-server into a new directory off / as described in the cyg/nfs readme. Running mount -m on the nfs-server computer all show -s (system/global) mounts. When I run without -r and use my usual NT account, I get the same result as running with -r and my usual NT account. Daemons fail to start. I enabled the security audit log but the only time I see a failure there is when I intentionally put in a bad password when prompted. Otherwise, no security errors when using my own account. I tried installing/starting portmap with my nt account and it would not go at all until I put it back to LocalSystem. (I have had no problems starting portmap until I tried this.) I do see a bit more detail in the application log for nfsd and mountd when they fail to start under my account. They both produce 2 log entries (4 total) when they fail (see attached). I have included the ones for nfsd. The ones for mountd are very similar so I did not include them. I notice that the app log refers to /var/log files. In /var/log the nfsd, portmap and mountd log files are owner/group = SYSTEM/root. Could this be significant? The only one containing data is nfsd.log but nothing in it seem to pertain to my problem, since the data only went in, apparently, when it was working right (with LocalSystem account). Any more ideas? -gene Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:26 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2320 : starting service `m' failed: redirect_fd: open (1, /var/log/nfsd.log): 13, Permission denied. Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:27 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2336 : starting service `nfsd' failed: execv: 1, Operation not permitted. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Some help with [re-]installation please
On Fri, 12 Mar 2004, Chris Green wrote: On Wed, Mar 10, 2004 at 10:10:18AM -0600, Brian Ford wrote: Since none of this is really specific to Cygwin/X, I've redirected this thread to the main cygwin list. You really should configure your mailer to honor the Reply-To header. I set it to the main Cygwin list so this off topic discussion wouldn't continue on the Cygwin/X list. Chris Green wrote: Once you have an existing Cygwin installation, the setup.exe chooser is also used to manage your Cygwin installation. Information on installed packages is kept in the /etc/setup/ directory of your Cygwin installation; if setup.exe cannot find this directory it will act just like you had no Cygwin installation. If setup.exe finds a newer version of an installed package available, it will automatically mark it to be upgraded. To Uninstall, Reinstall, or get the Source for an existing package, click on Keep to toggle it. Also, to avoid the need to reboot after upgrading, make sure to close all Cygwin windows and stop all Cygwin processes before setup.exe begins to install the upgraded package. What on earth does To Uninstall, Reinstall, or get the Source for an existing package, click on Keep to toggle it., mean??? Did you try it? Clicking on Keep transitions it to Uninstall, Reinstall, Source, etc. No it doesn't, this still confuses me, there are Keep, Prev, Curr and Exp and you can select each but I have no idea what they do. Clicking on Keep doesn't toggle it, it just selects it. You are (or I was) confusing the radio buttons at the top for Keep, Prev, Curr, and Exp (maybe they should be Keep, Revert, Upgrade, and Experimental? Does that help?) that apply to all packages, with the New column for each individual package (an override of sorts) that transitions through Keep, Reinstall, Source, Current version (Upgrade), Uninstall. HTH, but I'm obviously not a setup wizard. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
On Fri, 12 Mar 2004, Smith, Gene wrote: Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Smith, Gene Sent: 12 March 2004 15:38 The file nfs-server-2.2.47-2.README states: If you want your mount and NFS daemons to re-export mapped network drives, you will need to run them under an account other than Local System, and start both daemons with the '-r' option to enable re-exporting. I was able to install the daemons using the -r option with my usual login account (which also works for mapping network drives). However when I try to start them in the services gui I get an error stating the program terminated unexpectedly and the windows event log is no more helpful. I don't have a problem if I install/start the daemons without -r under the default LocalSystem rather than my own account. Is this a possible bug in the nfsd/mountd daemons or is it actually rejecting my account at start-time? (I get no complaints when I enter my uid/password+password.) If it it rejecting my account, what type of permissions do I need to be able to do this? cygcheck attached. Thanks, -gene It's most likely that the programs are actually starting OK but erroring out almost at once. You haven't tried the obvious experiments yet: what happens when you install them *with* -r under LocalSystem? What happens when you install them *without* -r under your usual login account? You've changed two things at one time: the command line flags, and the account under which it runs. You'll have to revert one of them to find out which of them caused the problem. Having said that, it's likely to be a Win ACL/privs problem. If you edit your local security policy to enable auditing of failures for all events, you may well get some useful information in your event viewer (security log) next time you try and start the server. It will certainly show up if the daemons are trying something that requires privileges enabled that they don't have. cheers, DaveK When I do -r with LocalSystem, all daemons start and I can mount as expected on remote computer, but can't see the mapped drive (which I have mounted on the computer running nfs-server into a new directory off / as described in the cyg/nfs readme. Running mount -m on the nfs-server computer all show -s (system/global) mounts. When I run without -r and use my usual NT account, I get the same result as running with -r and my usual NT account. Daemons fail to start. I enabled the security audit log but the only time I see a failure there is when I intentionally put in a bad password when prompted. Otherwise, no security errors when using my own account. I tried installing/starting portmap with my nt account and it would not go at all until I put it back to LocalSystem. (I have had no problems starting portmap until I tried this.) I do see a bit more detail in the application log for nfsd and mountd when they fail to start under my account. They both produce 2 log entries (4 total) when they fail (see attached). I have included the ones for nfsd. The ones for mountd are very similar so I did not include them. I notice that the app log refers to /var/log files. In /var/log the nfsd, portmap and mountd log files are owner/group = SYSTEM/root. Could this be significant? The only one containing data is nfsd.log but nothing in it seem to pertain to my problem, since the data only went in, apparently, when it was working right (with LocalSystem account). Any more ideas? -gene Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:26 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2320 : starting service `m' failed: redirect_fd: open (1, /var/log/nfsd.log): 13, Permission denied. Hmm, this one should be pretty obvious -- a chmod a+w /var/log/nfsd.log should fix this right up. Igor Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:27 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2336 : starting service `nfsd' failed: execv: 1, Operation not permitted. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-'Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a
Re: Subshell
Sorry, it should have been #! (beginners mistake, I guess) Thanks, Greg On Fri, 12 Mar 2004, Christopher Faylor wrote: On Fri, Mar 12, 2004 at 01:49:27PM -0600, Gregory Borota wrote: #/bin/bash echo Silly ( sleep 50 ( sleep 50 ) ) wait each subshell is sh.exe. Why would bash arbitrarily choose sh.exe as the subshell? I want to be be bash.exe. How do I force that without having to write bash -c P.S. Looked at cygwin faq, archive, didn't find the answer although this I would think has been brought up before. Hmm. c:\cd cygwin\bin c:\cygwin\binren sh.exe sh-saf.exe C:\cygwin\bin\sh.exe - C:\cygwin\bin\sh-saf.exe 1 file renamed c:\cygwin\binbash bash-2.05b$ (sleep 1) # works bash-2.05b$ cat /tmp/tst #!/bin/bash echo Silly (sleep 1 (sleep 1)) bash-2.05b$ /tmp/tst Silly bash-2.05b$ # works If bash used /bin/sh then it would have complained when running the above. I verified via strace that bash wasn't looking for sh.exe and settling for bash.exe if it didn't exist, too. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
Igor Pechtchanski wrote: Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:26 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2320 : starting service `m' failed: redirect_fd: open (1, /var/log/nfsd.log): 13, Permission denied. Hmm, this one should be pretty obvious -- a chmod a+w /var/log/nfsd.log should fix this right up. Igor You are right! That fixed it. There was already a w for the user SYSTEM but not on group and other. Guess that's what it needs. This fact should definitely be added to the readme or changed in the default install. I changed it on all three nfs related log files for good measure. I also noticed that nfs-server-config script did not work quite right the second time you ran it. It would not reload the daemons but complain they were already installed. I fixed that my rearranging the order of things. Also, it always complained that your mounts were not global even when they are. I also fixed that. Should I send a patch to someone or just send my fixed file to this list? Thanks for the help. -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
On Fri, 12 Mar 2004, Smith, Gene wrote: Igor Pechtchanski wrote: Event Type: Error Event Source: nfsd Event Category: None Event ID: 0 Date: 3/12/2004 Time: 2:07:26 PM User: SEA\SMITED Computer: 04J005 Description: The description for Event ID ( 0 ) in Source ( nfsd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: nfsd : PID 2320 : starting service `m' failed: redirect_fd: open (1, /var/log/nfsd.log): 13, Permission denied. Hmm, this one should be pretty obvious -- a chmod a+w /var/log/nfsd.log should fix this right up. Igor You are right! That fixed it. There was already a w for the user SYSTEM but not on group and other. Guess that's what it needs. This fact should definitely be added to the readme or changed in the default install. I changed it on all three nfs related log files for good measure. The log files are created by cygrunsrv when the service is first started. If cygrunsrv ran as LocalSystem, the logs will be owned by LocalSystem. The default umask (set in /etc/profile) is 022, which means turn off group and world write permissions. I doubt there's anything the nfs server itself can do about this. You might try changing the umask in /etc/profile, removing the log, and starting over... If this works, then it definitely should be in the README. I also noticed that nfs-server-config script did not work quite right the second time you ran it. It would not reload the daemons but complain they were already installed. I fixed that my rearranging the order of things. Also, it always complained that your mounts were not global even when they are. I also fixed that. Should I send a patch to someone or just send my fixed file to this list? Thanks for the help. -gene The nfs-server announcement (http://cygwin.com/ml/cygwin/2003-11/msg00267.html) says to send comments and questions to the cygwin list (i.e., here). To help the maintainer filter out the relevant messages, you might put something like [PATCH] nfs-server: ... as the subject. Hope this helps, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
Igor Pechtchanski wrote: On Fri, 12 Mar 2004, Smith, Gene wrote: You are right! That fixed it. There was already a w for the user SYSTEM but not on group and other. Guess that's what it needs. This fact should definitely be added to the readme or changed in the default install. I changed it on all three nfs related log files for good measure. The log files are created by cygrunsrv when the service is first started. If cygrunsrv ran as LocalSystem, the logs will be owned by LocalSystem. The default umask (set in /etc/profile) is 022, which means turn off group and world write permissions. I doubt there's anything the nfs server itself can do about this. You might try changing the umask in /etc/profile, removing the log, and starting over... If this works, then it definitely should be in the README. Changed umask in /etc/profile to 000. With nfs daemons running, rm'd the logfiles. Restarted daemons with no error. Files came back like this: -rw-r--r--1 SMITED mkgroup-0 Mar 12 17:18 mountd.log -rw-r--r--1 SMITED mkgroup-11869 Mar 12 17:21 nfsd.log -rw-r--r--1 SYSTEM root0 Mar 12 17:18 portmap.log No longer all SYSTEM/root but now like all other files in system SMITED/mkgroup- (except portmap which is still running as LocalSystem). Looks like the 1st time you start nfs as LocalSystem it makes it impossible to change unless you add write permissions or delete the mountd and ntfsd log files first. Also noticed that when I bop around in my mounted nfs directory on the client machine (doing cd's and ls), I get tons of errors in the nfsd.log file all saying this: nfsd[1860] 03/12/104 17:21 auth_clnt.c 327 : Unable to setgroups: invalid argument This happened when running as LocalSystem too. -gene I also noticed that nfs-server-config script did not work quite right the second time you ran it. It would not reload the daemons but complain they were already installed. I fixed that my rearranging the order of things. Also, it always complained that your mounts were not global even when they are. I also fixed that. Should I send a patch to someone or just send my fixed file to this list? Thanks for the help. -gene The nfs-server announcement (http://cygwin.com/ml/cygwin/2003-11/msg00267.html) says to send comments and questions to the cygwin list (i.e., here). To help the maintainer filter out the relevant messages, you might put something like [PATCH] nfs-server: ... as the subject. Hope this helps, Igor -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server re-exporting mapped network drives
One other related question. When I setup my nfs-server that re-exports shares and enter my network password to get it going, will I need to restart the nfs daemons every few months when I am required to change my password? Or will the nfs daemons (services) keep going without requiring me to give them my new password? Even after a reboot? If I have to re-enter the password (actually you have to enter it 4 times, twice for mountd and twice for nfsd) it might be easier and less hassle just to mirror the shares on my local nfs-server machine and just export the mirrored directory and rsync the mirror dir to the network share periodically using cron. I would probably have better performance too. -gene -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Difference between just having cygwin1.dll and running under cygw in
This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. Now if I could just get the Korn Shell in cygwin or integrate UWin into cygwin that would be really neat. George Hester __ Dave Korn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated Cygwin Package: rebase-2.3-1
On Fri, Mar 12, 2004 at 05:09:41PM -, Hughes, Bill wrote: I didn't Think You Really Meant To Say That. Hmm... I didn't have any problems with this warning all of the previous times I used it... :,) But I think he meant exactly what he said - Thanks for parsing the warning as I intended. If you *DON'T* *REALLY* know what you're doing, only use rebaseall. If you do know the implications (or you've been told to by One Who Knows), then you can use rebase, but still be careful. The above is what I meant. Anyway, I'll change the warning to be clearer the next time I release rebase. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: zsh 4.1.1-3 on W2000 hangs with command not found
On Fri, 12 Mar 2004, Thorsten Kampe wrote: Hi Thorsten, * Peter A. Castro (2004-03-08 20:39 +0100) On Mon, 8 Mar 2004, Thorsten Kampe wrote: Also, for the record, I've just tried the latest snapshot, 20040306, and running missing commands do not hang or have any other strange behaviour as your describe: ([EMAIL PROTECTED])[101] ~ % les zsh: correct 'les' to 'ls' [nyae]? n zsh: command not found: les zsh: 1240 exit 127 les ([EMAIL PROTECTED])[102] ~ % /bin/les zsh: no such file or directory: /bin/les zsh: 1245 exit 127 /bin/les ([EMAIL PROTECTED])[103] ~ % uname -a CYGWIN_NT-4.0 garfunkel 1.5.8s(0.111/4/2) 20040306 23:59:38 i686 unknown unknown Cygwin ([EMAIL PROTECTED])[104] ~ % cygcheck -s | grep zsh zsh 4.1.1-3 ([EMAIL PROTECTED])[105] ~ % setopt | grep correct correct correctall ([EMAIL PROTECTED])[106] ~ % This is just a tiny problems for me. There was a real problem with zsh where *completion* took a long time (it tried to do DNS lookup - according to my Personal Firewall - and timed out when I wasn't online and no DNS was available). This is gone. The other problem is no problem for me because I use the completion and therefor the correct mechanism is /very rarely/ triggered. After that zsh caches the answer and replies immdiately zsh: no such file or directory. (If I'm so dumb to try it again.) My example above has both correct and correctall on and I don't experience any problems no matter how many times I try to run a bad command. This goes for weither zsh tries to correct the command or not. But please be aware that there may be different problems. The one I described is with the correct function of zsh (and I figured that out just today). Davide Marchignoli's problem seems to be different: % aoidfjkl# immediately: zsh: command not found: aoidfjklj % /bin/aoidfjklj # hangs for about ten seconds until zsh: no such file or directory: /bin/aoidfjklj Sorry, mine returnes immediately, no delay at all. And this is on an old 400MHz PII running under a vmware emulator. Oh, and I tried this same setup, with the latest snapshot on a 1.7Ghz system running MS Windows native without any problems either. I also tried both of these on network mounted drives and didn't have any delays or problems. I feel you should examine your environment thoroughly. Perhaps you have more than one copy of cygwin1.dll in your PATH? When you last upgraded, are you sure you existing all cygwin based processes before starting a new shell window? I did that. My .zshrc is *exactly* the same on this host and on my Gentoo Linux where everything is fine. I tried to narrow the problem by deleting * /etc/zprofile * /etc/profile.d/zshell.zsh * ~/.zshenv * ~/.zprofile * ~/.zlogout * ~/.zlogin I've removed all of these and have only correct and correctall set (btw: interactive, shinstdin and zle are also set by default), but still can't reproduce this. Sorry, I just can't seem to make it hang. and everything in .zshrc except setopt correct correctall. It's those two options that make zsh hang. I even unset all environment variables inherited from Windows. No change. If you have any hint how to find the problem I'd be glad to assist (strace). By the way - I freshly installed Cygwin on this box and the Windows installation (Windows XP SP1) is two months old. I deactived my PF (Kerio - newest version) and even detached from my NetWare. Even the Novell Client is the latest one. And locate shows only one cygwin1.dll I think a better search mechanism might be to see what your system PATH it set to, in the control panel, and do a Windows Find for cygwin1.dll and see there is more than one in the PATH. At this point, I think you need to go through the problem reporting process as outlined in http://www.cygwin.com/problems.html. Specifically, your cygcheck output. Additionally, I'd like you to run 'uname -a', 'setopt', 'env' and 'set' from within zsh with both correct and correctall off. Send all of that to the list, as attachments, and I'll analyse them. Thorsten -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem when compiling signal.h in GCC with strict ISO C options turned on
I get this message a few times when I use gcc with strict settings. On my own installation I gave the unnamed structs and unions an name and this seemed to resolve this. Although this doesn't do more then generate a warning when using a very strict c compiler it should be resolved i think :) Message: /usr/include/cygwin/signal.h:48: error: ISO C doesn't support unnamed structs/unions gcc flags: -ggdb -ansi -W -Wall -Werror -pedantic-errors -O2 -Wformat=2 -Wno-unused -DPOSIX -DPOSIX_SOURCE Grtz, Bart van der Werf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Difference between just having cygwin1.dll and running under cygw in
* George Hester (2004-03-13 01:24 +0100) This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. Now if I could just get the Korn Shell in cygwin or integrate UWin into cygwin that would be really neat. George Hester __ Dave Korn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today pdksh -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
minor bug in cygrunsrv-0.98 help function
Hi: The option --neverexits is mispelled as --neverexists in the help function: [EMAIL PROTECTED] cygrunsrv --help | fgrep neverexi -n, --neverexists Service should never exit by itself. [EMAIL PROTECTED] strings - /usr/bin/cygrunsrv.exe | fgrep neverexi neverexits --neverexists is only allowed with --install Only one --neverexists is allowed -n, --neverexists Service should never exit by itself. [EMAIL PROTECTED] cygrunsrv --version cygrunsrv V0.98, Feb 4 2004 Copyright 2001, 2002, 2003, 2004 Corinna Vinschen This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute it under the terms of the GNU General Public License; see the file named COPYING for details. Written by Corinna Vinschen and Fred Yankowski. HTH, -- Tony -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
x-start-menu-icons doesn't install on a W2K german OS
Hi see subject. Following is a dir listing (inclusive control-chars) from my Documents and Settings directory on a german W2K system. 11:13 AM [513] pwd /c/Dokumente und Einstellungen/All Users [EMAIL PROTECTED] /c/Dokumente und Einstellungen/All Users 11:13 AM [514] ls -lat --show-control-chars total 0 drwxr-xr-x+ 9 root admin4096 Mar 12 10:59 ./ drwxrwxrwx+ 3 vzelladmin 0 Mar 12 10:59 Startmen³/ - got created by setup.exe drwxrwxr-x+ 7 root system 4096 Apr 13 2003 ../ drwxr-xr-x+ 2 root admin 0 Mar 31 2003 Desktop/ drwxr-xr-x+ 3 root admin4096 Feb 23 2003 Startmenü/ - This was there already drwxrwxrwx+ 2 root admin 0 May 29 2002 DRM/ drwxr-xr-x+ 4 root admin 0 Feb 24 2002 Dokumente/ drwxr-xr-x+ 3 root admin 0 Feb 5 2002 Anwendungsdaten/ drwxr-xr-x+ 2 root admin 0 Feb 5 2002 Vorlagen/ [EMAIL PROTECTED] /c/Dokumente und Einstellungen/All Users Here the relvant part from setup.log.full 2004/03/12 10:59:24 running: D:\\bin\sh.exe -c /etc/postinstall/fontconfig.sh 2004/03/12 10:59:27 running: D:\\bin\sh.exe -c /etc/postinstall/X-start-menu-icons.sh mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\bitmap.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\dpsexec.lnk failed; does the target directory exist? dpsexec:Display PostScript command interface:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Tools:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\dpsinfo.lnk failed; does the target directory exist? dpsinfo:The Display PostScript extension:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\editres.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\fc-list.lnk failed; does the target directory exist? fc-list:List available FreeType fonts:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Toys\glxgears.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\glxinfo.lnk failed; does the target directory exist? glxinfo:GLX information:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Toys\ico.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\oclock.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\showrgb.lnk failed; does the target directory exist? showrgb:List rgb database:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Games\texteroids.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\viewres.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\wmagnify.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xbiff.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xcalc.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xclock.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\xconsole.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Tools\xcutsel.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\xditview.lnk failed; does the target directory exist? mkshortcut: Saving c:\Dokumente und Einstellungen\All Users\Startmen³\Programme\Cygwin-X\Information\xdpyinfo.lnk failed; does the target directory exist? xdpyinfo:Display information:/c/Dokumente und Einstellungen/All Users/Startmen³/Programme/Cygwin-X/Information:: mkshortcut: Saving c:\Dokumente und Einstellungen\All
Re: Some help with [re-]installation please
On Wed, Mar 10, 2004 at 10:10:18AM -0600, Brian Ford wrote: I had all the ftp'ed files left from installing cygwin previously sitting in a directory on a networded drive, could I have used these to re-install cygwin rather than downloading everything again? If so, how does one do it? Yes. Choose Install from Local Directory instead of Install from Internet, and point setup there. Keep in mind, however, you would have missed out on all the new and exciting updates :). There are a number of different directories, one for each FTP site I've used. This is the part I am not sure how to handle. setup.exe is very clever actually, it looks through *all* the ftp directories and merges what you have into one list. I really find the window where you select what to download, etc. *very* confusing, some of the wording is very odd. Two examples from the User's Guide which I find difficult to understand are:- You can change setup.exe's view style, which is helpful if you know the name of a package you want to install but not which category it is in. Click on the View button and it will rotate between Category (the default), Full (all packages), and Partial (only packages to be upgraded). If you are familiar with Unix, you will probably want to at east glance through the Full listing for your favorite tools. So what does 'Partial' mean? I can see that Category means all packages sorted into types, Full means all in alphabetical order but what does Partial mean? Does it mean only display packages that I've got already? I found it confusing at first too :). It also gives you 'Not installed' which is what I want as it indicates the packages that are downloaded in the local cache but not installed. Just what I need for a re-install after losing my disk. Once you have an existing Cygwin installation, the setup.exe chooser is also used to manage your Cygwin installation. Information on installed packages is kept in the /etc/setup/ directory of your Cygwin installation; if setup.exe cannot find this directory it will act just like you had no Cygwin installation. If setup.exe finds a newer version of an installed package available, it will automatically mark it to be upgraded. To Uninstall, Reinstall, or get the Source for an existing package, click on Keep to toggle it. Also, to avoid the need to reboot after upgrading, make sure to close all Cygwin windows and stop all Cygwin processes before setup.exe begins to install the upgraded package. What on earth does To Uninstall, Reinstall, or get the Source for an existing package, click on Keep to toggle it., mean??? Did you try it? Clicking on Keep transitions it to Uninstall, Reinstall, Source, etc. No it doesn't, this still confuses me, there are Keep, Prev, Curr and Exp and you can select each but I have no idea what they do. Clicking on Keep doesn't toggle it, it just selects it. -- Chris Green ([EMAIL PROTECTED]) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: cygutils-1.2.5-1
Cygutils is a collection of useful(?) tools for the cygwin platform. This release provides an enhanced mkshortcut tool, as well as fixing a few bugs. Changes since 1.2.4-1 * mkshortcut has two new options, -s (startup norm|max|min mode) -d|--desc string to control the description field of the shortcut (which also sets the tooltip text) 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. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Charles Wilson
