Re: corrupted files: docbook, lintntl1
On Feb 7 21:05, Charles Wilson wrote: Christopher Faylor wrote: Could the package maintainers for the packages in the subject provide a URL where I can fix this problem? libintl1 appears to be corrupted on mirrors.kernel.org only (ftp.gwdg.de and sunsite.icm.edu.pl look OK). The correct file is here: http://cygutils.fruitbat.org/libintl1-0.10.40-1-src.tar.bz2 size : 1.3M md5sum: 578ba3edc1f077e5b27716f18bc3f7d1 Thanks. Soebody uploaded the file but the result has been named libintl1-0.10.40-1-src.tar.bz2.1 by wget, apparently. I renamed it to libintl1-0.10.40-1-src.tar.bz2. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
ATT ksh93
This is a followup to the request for ksh93 on [EMAIL PROTECTED] I repackaged and reposted the binary package to include a postinstall script that plays nice with other ksh implementations by installing /bin/ksh93.exe and making a /bin/ksh.exe = ksh93.exe symlink if /bin/ksh.exe doesn't exist. http://www.research.att.com/sw/download/beta/astksh-20050202-1.tar.bz2 -- Glenn Fowler -- ATT Research, Florham Park NJ --
new package: mined text editor
Hello, I have released version 2000.10 of my editor mined. I had proposed it as a cygwin package last year and got the votes and a package review. This is a new version and I suppose the package should be alright now. The setup.hint file and the binary and source packages are available for download from the directory http://towo.net/mined/cygwin/ The setup.hint file is also shown below. I appreciate integration of the package into the cygwin distribution. Kind regards, Thomas Wolff # cygwin setup file @ mined sdesc: Powerful text mode editor with extensive Unicode and CJK encoding support. category: Editors requires: cygwin ldesc: Mined is a powerful text editor with a comprehensive and easy-to-use user interface and fast, small-footprint behaviour. It was the first editor that provided Unicode support in a plain-text terminal. It now has both extensive Unicode and CJK support offering many specific features and covering special cases that other editors are not aware of (like auto-detection features and automatic handling of terminal variations, or Han character information). And basically, it is an editor tailored to efficient editing of plain text documents and programs, with features and interactive behaviour designed for this purpose. Mined Overview Good interactive features * Intuitive user interface * Logical and consistent concept of navigating and editing text (without ancient line-end handling limitations or insert/append confusion) * Supports various control styles: Editing with command control, function key control, or menu control Navigation by cursor keys, control keys, mouse or scrollbar * Comprehensive menus (driven by keyboard or mouse) * HOP key paradigm doubles the number of navigation functions that can be most easily reached and remembered by intuitively amplifying the associated function * Immediate adjustment if the window size is changed, in any state of interaction Versatile character encoding support * Extensive Unicode support, including double-width and combining characters, script highlighting, various methods of character input support (mapped keyboard input methods, mnemonic and numeric input), supporting CJK, Vietnamese, Hebrew, Arabic, and other scripts * Support of bidirectional terminals, Arabic ligature joining * East Asian character set support: handling of major CJK encodings (including GB18030 and full EUC-JP with combining characters) in either Unicode terminal or CJK terminal * Support for a variety of 8 bit encodings (mapped to Unicode) (with combining characters for Vietnamese and Thai) * Support of CJK input methods by enhanced keyboard mapping including multiple choice mappings (handled by a pick list menu); characters in the pick list being sorted by relevance of Unicode ranges * Han character information with description and pronunciation * Auto-detection of text character encoding, edits files with mixed character encoding sections (e.g. mailboxes), transparent handling of UTF-16 encoded files * Auto-detection of UTF-8 / CJK terminal mode and detailed features (like different Unicode width and combining data versions) * Encoding support tested with: xterm, mlterm, hanterm, cxterm, rxvt, linux console Many useful text editing capabilities * Many text editing features, e.g. paragraph wrapping, auto-indentation and back-tab, smart quotes (with quotation marks style selection and auto-detection) and smart dashes * Search and replacement patterns can have multiple lines * Cross-session paste buffer (copy/paste between multiple - even subsequent or remote - invocations of mined) * Marker stack for quick return to previous text positions * Multiple paste buffers (emacs-style) * Program editing features, HTML support and syntax highlighting, identifier and function definition search, also across files; structure input support * Text and program layout features; auto-indentation and undent function (back-tab), numbered item justification * Systematic text and file handling safety, avoiding loss of data * Visible indications of special text contents (TAB characters, different line-end types, character codes that cannot be displayed in the current mode) * Full binary transparent editing with visible indications (illegal UTF-8 or CJK, mixed line end types, NUL characters, ...) * Print function that works in all text encodings * Optional emacs command mode Small-footprint operation and portability * Plain text mode (terminal) operation, supporting wide range of terminals * Instant start-up * Runs on many platforms: Unix (Linux/Sun/HP/BSD/Mac and more), DOS (djgpp), Windows (cygwin) * Makefiles also support legacy systems
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Alexander Gottwald wrote: On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps Confirmed that I got it running fine on cygwin 1.3.x If you do make any progress on 1.5.x please report back to the list! David
Linking with additional libraries...
Hey! I'm experimenting with some new stuff and have to add so that msimg32.dll is linked when building XWin.exe, tried to add it manually in Xserver/Makefile and Imakefile but it still complains about underfined references to functions. I also took a look in xc/config/cf/* but found nothing of interest. Cheers, Sebastian Haby
Re: Linking with additional libraries...
On Tue, 8 Feb 2005, Sebastian Haby wrote: Hey! I'm experimenting with some new stuff and have to add so that msimg32.dll is linked when building XWin.exe, tried to add it manually in Xserver/Makefile and Imakefile but it still complains about underfined references to functions. I also took a look in xc/config/cf/* but found nothing of interest. Check how opengl32 is added to the link list. BTW: What kind of chages are these? Icon/Image loading stuff? Please make sure msimg32.dll is available on all target systems. Otherwise you'll have to resolve the symbols dynamicly. Ah, you're trying to use AlphaBlend? MSDN states these functions are available in Windows 98 or Windows 2000 and later. But not in Windows 95 or NT. This definitly means you have to resolve the function dynamicly. Check how winprocarg.c loads EnumDisplayMonitors. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Linking with additional libraries...
Hi. In Xserver/Imakefile, you will find following line. XWINW32 = -lgdi32 -lwsock32 $(XWINGL32) $(PTHREADLIB) Add -lmsimg32. And make Makefile make Makefiles. Bye Kensuke Matsuzaki
XWindows Errors running ddd under Cygwin
I would have done an archive search before submitting this question, but as many of you know, the Search functionality is switched off because of the recent crash. So my question is: do I have to worry about these warning messages I get while running ddd? I am having other problems, and am wondering if they are related. The way I run it is: 1 - launch Cygwin.bat to open bash shell with proper enviornment variables (HOME, HOMEPATH) defined 2 - type 'startx '. 3 - after X started, type 'ddd' 4 - Use File:Open menu to find executable and load it. But at this point I see the warnings: Warning: Name ItemsList Class: XmList Parent refused resize request. Second XtMakeGeometryRequest() failed. ... And: Warning: XtRemoveGrab asked to remove a widget not on the list. So the most fundamental question is: do any of these warnings indicate that my installation of X is incomplete? I could NOT find packages listed by Cygwin's setup.exe to correspond to all the X features/packages listed by ddd --config. But it does behave much better after dowloading and installing LessTiff. I just installed all these things today or last week using setup.exe (Devel package last week, and lots of X stuff today), so they _should_ be quite up-to-date. = --- Matthew Johnson [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
winsup/cygwin ChangeLog pipe.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-02-08 16:19:59 Modified files: cygwin : ChangeLog pipe.cc Log message: * pipe.cc (fhandler_pipe::read): Remove hold over from old read_state implementation. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2704r2=1.2705 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pipe.cc.diff?cvsroot=uberbaumr1=1.72r2=1.73
src/winsup/cygwin ChangeLog cygthread.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-08 16:56:02 Modified files: winsup/cygwin : ChangeLog cygthread.cc Log message: * cygthread.cc (cygthread::detach): Just test thread handle after signal arrived, don't wait infinitely for it. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2705r2=1.2706 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygthread.cc.diff?cvsroot=srcr1=1.57r2=1.58
src/winsup/cygwin ChangeLog times.cc include/s ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-08 20:59:41 Modified files: winsup/cygwin : ChangeLog times.cc winsup/cygwin/include/sys: utime.h Log message: * times.cc (timeval_to_filetime): Define first parameter const. (utimes): Define second parameter to const according to SUSv3. (utime): Ditto. * include/sys/utime.h (utime) : Change declaration accordingly. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2706r2=1.2707 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.56r2=1.57 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/sys/utime.h.diff?cvsroot=srcr1=1.1r2=1.2
Re: patch to allow touch to work on HPFS (and others, maybe??)
On Feb 7 14:37, Mark Paulus wrote: So, what it really seems to boil down to is for those filesystems that support doing timestamp updating via FILE_WRITE_ATTRIBUTES (NTFS systems) we should use FILE_WRITE_ATTRIBUTES, and for those that don't (HPFS, etc), they should use GENERIC_WRITE? Yes. I'm wondering though, if that's the filesystem or OS/2 which choke on FILE_WRITE_ATTRIBUTES. Unfortunately, during my brief perusal of MSDN, I didn't see an easy way to determine the file system type. Have a look into path.cc, fs_info::update (). Test the filesystem name in fs_info::update and add a flag to fs_info which tells us that FILE_WRITE_ATTRIBUTES is supported (which is valid for NTFS and FAT, btw.). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Installing in root (was Re: Linux Journal Cygwin article)
linda w wrote: Perhaps he has read that many developers and users on this list use C:\ as the root diretory and have no problems. I had the impression that the advice to install into a subdirectory was more of a Covering One's Behind (COB?) when presenting cygwin as a commercial solution to vendors. I find it more useful to have it in the root directory, as I use my cygwin tools and shell to manage my XP machine instead of the Windows tools. I have yet to run into a problem with conflicting software ... Sorry but that's a horrible idea. I would never want to do that personally. If you install Cygwin as a subdirectory for itself it's much easier to delete, backup, modify, etc. For example if you need multiple installations around for testing you just umount -A, rename the dir to something else, and reinstall a new one. If you want /home on Cygwin and windows to match then just mount it that way. You can mount things however you want them, but that doesn't mean you have to have the files physically in the root dir. Mount c:\windows on /windows, c:\documents and settings\ on /home, whatever. That's no justification for installing Cygwin in the root directory. Brian -- 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/
Can't cd into directory
I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. -- 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: Can't cd into directory
Please post output of mount -p acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. -- 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: RFE: enhance setup.exe to used cached mirrors file
On Feb 8 17:22, Erik de Castro Lopo wrote: On Mon, 7 Feb 2005 22:28:32 -0500 (EST) Igor Pechtchanski [EMAIL PROTECTED] wrote: The best way to second such requests is with a patch. Remember, http://cygwin.com/acronyms/#PTC. :-) Where would I find the code to setup.exe? I had a look in the main CVS tree but couldn't find it. See http://sourceware.org/cygwin-apps/setup.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com 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: hyperthreading fix, try #1
Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) - Jörg -- 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: bash: tab completion failure from (but not at) /
On Feb 8 07:19, [EMAIL PROTECTED] wrote: Recent remarks (I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released) suggest that an updated cygwin1.dll might be imminent. Please could I mention a minor but annoying glitch described along with Corinna's immediate and effective fix at http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has re-emerged in recent snapshots, at least since http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna records her perplexity (weird) at this re-emergence. Things worked properly in snapshot 20041222 but fail from 20041223. Nevertheless, that's a bash problem. Is our bash maintainer still around? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com 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: hyperthreading fix, try #1
On Feb 8 09:31, J?rg Schaible wrote: Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) We could ask the Queen to bestow the OM upon Chris. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com 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: svn on apache on Cygwin?
Steve Kelem wrote: Does anyone have a pointer on how to build apache on Cygwin so that it supports svn? I'm working on it, but it's still at the trailblazing stage, rather than the guidebooks available stage. Use svnserve instead. Max. -- 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: RFE: enhance setup.exe to used cached mirrors file
On Tue, 8 Feb 2005 09:30:45 +0100 Corinna Vinschen [EMAIL PROTECTED] wrote: See http://sourceware.org/cygwin-apps/setup.html Got it. Thanks. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ We can build a better product than Linux -- Microsoft Corp.'s Windows operating-system chief, Jim Allchin. One has to wonder why, with their huge resources, they haven't. -- 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: Can't cd into directory
Sure thing: [EMAIL PROTECTED] ~ $ mount -p Prefix Type Flags /cygdrive system binmode [EMAIL PROTECTED] ~ $ - Original Message - From: Jörg Schaible [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, February 08, 2005 12:26 AM Subject: RE: Can't cd into directory Please post output of mount -p acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. -- 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/
Possible bug
try this : $ AUTOHEADER=autoheader`echo $AUTOCONF | sed 's/.*autoconf//'` $ test -x $AUTOHEADER $ echo $? the result in cygwin is 1 but the result in fedora is 0 this is not enabling me to cross compile tvtime -- 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: Possible bug
oops in fedora its 1
code in tvtime boot strap thats failing
-
test -x $AUTOHEADER ||
AUTOHEADER=autoheader`echo $AUTOCONF | sed 's/.*autoconf//'`
AUTOHEADER=`type -p $AUTOHEADER` ||
{
echo `basename $0`: GNU Autoconf installed improperly 12
exit 2;
}
in tvtime bootstrap under cygwin im geting the message
GNU Autoconf installed improperly
but not in fedora
bye,
Vijay
On Tue, 8 Feb 2005 15:41:20 +0530, Vijay Kiran Kamuju
[EMAIL PROTECTED] wrote:
try this :
$ AUTOHEADER=autoheader`echo $AUTOCONF | sed 's/.*autoconf//'`
$ test -x $AUTOHEADER
$ echo $?
the result in cygwin is 1
but the result in fedora is 0
this is not enabling me to cross compile tvtime
--
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: perl Win32 lib support
Yitzchak Scott-Thoennes schrieb: On Mon, Feb 07, 2005 at 06:42:21PM -0800, linda w wrote: I thought there had been a fix in the works for this problem -- I wanted to write a program using cygwin perl to access/modify the Registry. When I load the Win32 package from cpan and try building it, I get a familiar error message IsWinNT is undefined, so building and installing cpan registry access routines isn't possible. Is there something else that would break if IsWinNT is set to true if the underlying OS is NT based (or IsWin95 for Win9x/Me)? I might be able to use ActiveState's Perl, but it doesn't play so well with CPAN and doesn't seem to handle Cygwin paths very well either. Was there a work-around for this? Upgrade to perl5.8.6, which addresses the IsWinNT-missing problem. Also, I believe Reini will be releasing a new version of perl-libwin32 real soon now. The interim version is at http://xarch.tu-graz.ac.at/publ/cygwin/release/perl-libwin32 (use http://xarch.tu-graz.ac.at/publ/cygwin/ as setup User URL:) But I want to wait a bit for Rafael's answer about maintainership change, and for confirmation on the new libwin32 list about my proposed new Win32::Process functions and version bump. perl-win32-gui and perl-win32-api will be the next. New clamav and postgresql versions are also pending. Still some problems there (upstream and here). -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: tee piping to head gives error message
Don't break head. We won't want Argument list too long when piping a stream to head. -- Original Message --- From: Buchbinder, Barry (To: cygwin-cygwin.com Sent: Mon, 7 Feb 2005 13:49:49 -0500 Subject: RE: tee piping to head gives error message At Monday, February 07, 2005 1:13 PM, Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Buchbinder, Barry (NIH/NIAID) Sent: 07 February 2005 17:28 As described in the Subject. Though it seems that everything works OK; tee just gives and error message under some circumstances. /tmp cat stafflist.htm | tee ttt | head /dev/null tee: standard output: Broken pipe So the file that tee write looks good and the write error is only to the pipe. That'll be because head closed the pipe, and tee was still trying to write into it. Further experimentation supported that. Inserting cat between tee and head did not eliminate the error message, while inserting sort did. So head seems to be passing on the number of lines that ones asks it to pass on. Given that the purpose of head is to print the first few lines of a file, it kind of makes sense to me that it would close the file after it's read them rather than keeping the input file open and manually reading-and-discarding the entire rest of it for no good reason. Agreed. So I reckon this is as-expected and by-design behaviour. with the upstream maintainers, or to patch himself. (I won't complain if he doesn't patch it. Taking on coreutils was quite a commitment -- well deserving of the two gold stars -- and I know that fixing this may be a low priority.) Unfortunately, though PTC, I'm not capable of providing a patch. In any case, tee seems to save its input as desired, so while the error message is annoying and misleading, I suppose that one can live with it. --- Cut --- -- This message and any attachments may contain information that is protected by law as privileged and confidential, and is transmitted for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by e-mail, and permanently delete this e-mail. -- This message has been scanned for viruses and dangerous content by MailScanner and F-Prot. -- 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/
cygwin1.dll crash
Hi I've just run an setup to add some fonctionalities (cron) to my cygwin install, but it crashed at the end of the configuration process with the following message the procedure entry point _impure_ptr could not be located in the dynamic link library cygwin1.dll Now, wathever I try to rin I've got this error message any idea is welcome:-/ thks -- 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: cygwin1.dll crash
-Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 13:20 Hi I've just run an setup to add some fonctionalities (cron) to my cygwin install, but it crashed at the end of the configuration process with the following message the procedure entry point _impure_ptr could not be located in the dynamic link library cygwin1.dll Now, wathever I try to rin I've got this error message any idea is welcome:-/ Try this: Problem reports: http://cygwin.com/problems.html 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: Possible bug
but the below code in tvtime bootstrap works fine
--
test -x $AUTOCONF ||
AUTOCONF=`type -p autoconf2.50` ||
AUTOCONF=`type -p autoconf` ||
{
echo `basename $0`: cannot find GNU Autoconf 12
exit 1;
}
On Tue, 8 Feb 2005 16:01:54 +0530, Vijay Kiran Kamuju
[EMAIL PROTECTED] wrote:
oops in fedora its 1
code in tvtime boot strap thats failing
-
test -x $AUTOHEADER ||
AUTOHEADER=autoheader`echo $AUTOCONF | sed 's/.*autoconf//'`
AUTOHEADER=`type -p $AUTOHEADER` ||
{
echo `basename $0`: GNU Autoconf installed improperly 12
exit 2;
}
in tvtime bootstrap under cygwin im geting the message
GNU Autoconf installed improperly
but not in fedora
bye,
Vijay
On Tue, 8 Feb 2005 15:41:20 +0530, Vijay Kiran Kamuju
[EMAIL PROTECTED] wrote:
try this :
$ AUTOHEADER=autoheader`echo $AUTOCONF | sed 's/.*autoconf//'`
$ test -x $AUTOHEADER
$ echo $?
the result in cygwin is 1
but the result in fedora is 0
this is not enabling me to cross compile tvtime
--
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: Can't cd into directory
On Tue, 8 Feb 2005, Jörg Schaible wrote: acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. Please post output of mount -p Instead of providing information bit by bit, please see the Cygwin posting guidelines at http://cygwin.com/problems.html for the necessary system information. Oh, and please don't top-post. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: cygwin1.dll crash
-Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 13:40 Hi here you have a syscheck log Let's take a look Path: C:\oracle\ora90\bin C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 Ah. A version of Perl. And not ActiveState perl. Very likely compiled and running under cygwin. An old version of the dll, most likely. If my theory is right, you're going to have trouble as long as both the Oracle directories and the cygwin directories are in your PATH setting at the same time. Would you mind posting back the output you get from running dir /w C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 C:\oracle\ora90\bin in a DOS shell? I'd like to see. To fix the cygwin installation, you could shut down all oracle-related software, including Apache if that's running, then move C:\cygwin\bin to the front of your PATH, and re-run setup.exe; that should update your installation OK. But then you might later have trouble running oracle stuff. So the best solution would probably be to remove cygwin from your PATH altogether, and add the command PATH C:\cygwin\bin;%PATH% to your C:\cygwin\Cygwin.bat startup file. 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: hyperthreading fix, try #1
-Original Message- From: cygwin-owner On Behalf Of Corinna Vinschen Sent: 08 February 2005 08:48 On Feb 8 09:31, J?rg Schaible wrote: Brian Gallew wrote on Monday, February 07, 2005 2:18 PM: Christopher Faylor wrote: Fixing that seems to have fixed my hyperthreading problems. I have run three invocations of the scripts for four days without a hiccup. Previously, I had problems within minutes. Go, you! Someone should give you a gold star for this. IMHO Chris needs more something like a life-time award :) We could ask the Queen to bestow the OM upon Chris. We could ask the Buddha to bestow the AUM upon him too! 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: Installing in root (was Re: Linux Journal Cygwin article)
-Original Message- From: cygwin-owner On Behalf Of Brian Dessent Sent: 08 February 2005 08:12 linda w wrote: Perhaps he has read that many developers and users on this list use C:\ as the root diretory and have no problems. I had the impression that the advice to install into a subdirectory was more of a Covering One's Behind (COB?) when presenting cygwin as a commercial solution to vendors. I find it more useful to have it in the root directory, as I use my cygwin tools and shell to manage my XP machine instead of the Windows tools. I have yet to run into a problem with conflicting software ... Sorry but that's a horrible idea. I would never want to do that personally. If you install Cygwin as a subdirectory for itself it's much easier to delete, backup, modify, etc. For example if you need multiple installations around for testing you just umount -A, rename the dir to something else, and reinstall a new one. If you want /home on Cygwin and windows to match then just mount it that way. You can mount things however you want them, but that doesn't mean you have to have the files physically in the root dir. Mount c:\windows on /windows, c:\documents and settings\ on /home, whatever. That's no justification for installing Cygwin in the root directory. /ZIPPY Yow! Confusing the root directory of a single drive with the root of an entire filesystem tree gives me cognitive dissonance! /ZIPPY 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: perl winpid?
Gerrit P. Haase schrieb: Yitzchak Scott-Thoennes wrote: On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote: Igor Pechtchanski schrieb: On Sun, 6 Feb 2005, Reini Urban wrote: I feel quite stupid now, but found nothing simple. How to get the winpid from the current process in cygwin's perl? We will check out there where this cygwin specific functionality will go to. Win32::Process::CygwinToWin32ProcessID() is my suggestion. I'd rather see them in the Proc:: namespace, and I think it would make sense to put them in perl's cygwin.c itself, if Gerrit is willing to release yet another perl-5.8.6. If this sounds OK, I'll come up with a patch. I have no problem with another release. And I agree that such important functions should go inside perl. Ok. Then we won't have to pollute the Win32::Process namespace with this cygwin-only functionality. And we don't have to wait for the still unmaintained libwin32 upstream. README.cygwin, cygwin/cygwin.c: =item cygwin32_winpid_to_pid($pid) Returns the windows process ID for the given cygwin pid. cygwin-only. =item cygwin32_pid_to_winpid($pid) Returns the cygwin process ID for the given windows pid. cygwin-only. Or as seperate Proc::Cygwin package, which could be maintained at CPAN and go to vendor_perl within gerrit's perl package? Proc::Cygwin::Win32ProcessID($pid) Proc::Cygwin::CygwinProcessID($winpid) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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: cygwin1.dll crash
here you have the output for dir /w its quite huge I've put the cygwin path in top of my PATH var. but still the same problem regards On Tue, 8 Feb 2005 14:37:23 -, Dave Korn [EMAIL PROTECTED] wrote: -Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 13:40 Hi here you have a syscheck log Let's take a look Path: C:\oracle\ora90\bin C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 Ah. A version of Perl. And not ActiveState perl. Very likely compiled and running under cygwin. An old version of the dll, most likely. If my theory is right, you're going to have trouble as long as both the Oracle directories and the cygwin directories are in your PATH setting at the same time. Would you mind posting back the output you get from running dir /w C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 C:\oracle\ora90\bin in a DOS shell? I'd like to see. To fix the cygwin installation, you could shut down all oracle-related software, including Apache if that's running, then move C:\cygwin\bin to the front of your PATH, and re-run setup.exe; that should update your installation OK. But then you might later have trouble running oracle stuff. So the best solution would probably be to remove cygwin from your PATH altogether, and add the command PATH C:\cygwin\bin;%PATH% to your C:\cygwin\Cygwin.bat startup file. 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/ dir.out Description: Binary data -- 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: Can't cd into directory
acidblue wrote: acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, February 08, 2005 12:26 AM Subject: RE: Can't cd into directory Please post output of mount -p Sure thing: [EMAIL PROTECTED] ~ $ mount -p Prefix Type Flags /cygdrive system binmode [EMAIL PROTECTED] ~ $ You should probably double check the pages found here: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames in the Using Cygwin document. Probably you have a problem with the mount table. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin -- 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: cygwin1.dll crash
-Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 14:50 here you have the output for dir /w its quite huge Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 [.] [..] a2p.exe perl.dll perl.exe perl5.00503.exe perl95.exeperlglob.exe 6 File(s)987.136 bytes This is ActiveState perl, so I was wrong in my first guess. I'm still suspicious that it's the root cause of the trouble though; if any of the setup.exe post-install scripts rely on perl, they are liable to invoke active state perl instead of cygwin perl, and break when it fails to understand cygwin-style POSIX paths. I've put the cygwin path in top of my PATH var. but still the same problem Hmm, peculiar. May need some more thinking time over this. Precisely how did you set it? If you do it using the PATH command in a DOS prompt, that wouldn't affect a copy of setup.exe that you launched from explorer, you do need to set it in Start Menu / Settings / Control Panel / System / Advanced / Environment Variables. Try setting your PATH to nothing but these entries: C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem and see if that helps any. 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/
Read the reports before you trade
Test message -- 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/
Couldn't create signal pipe - User permission problem? (IIS6/Win2003)
Dear List, I am seeking advice regarding the permissions it necessary for a windows system user to have in order to successfully execute a binary that uses cygwin1.dll. The binary in question is mkisofs.exe as supplied with the cdrtools-2.01-win32-bin package. The package is supplied with cygwin1.dll version 1.5.12, which I believe to be up to date. My operating system is Windows 2003 server. When I try to execute the binary it exists with the error message shown below: 3 [main] ? 1148 cygheap_user::init: OpenProcessToken(), Win32 error 5 D:\cgi-bin\cdrtools-2.01-win32-bin\mkisofs.exe (1148): *** couldn't create signal pipe, Win32 error 0 I have identified Win32 error 5 as an access denied error. I have verified that NTFS permissions are not at fault using a utility called FileMon from SysInternals to check file system accesses and their status. Im quite certain that the NTFS permissions are not the problem. I am not executing mkisofs.exe from a command prompt or shell, but rather as a CGI application from a PHP script running under the IIS6 web server. This worked fine under Windows 2000 on IIS5, and so I suspect that the problem relates to tighter security settings on IIS6 / Windows 2003. I found this thread: http://cygwin.com/ml/cygwin/2003-10/msg00447.html I granted the user the application pool is running under create global objects permission as suggested. Additionally I have granted the user adjust memory quotas for a process and replace a process at token level as Microsoft suggests is necessary for CGI applications. But still the process exits with the same error message. And so my question is, does anyone have any idea which permission might be missing and be causing this error to occur? And does anyone have any experience with calling binaries that use cygwin1.dll as a CGI application under Windows 2003 and IIS6? Thank you for your time, Andrew NB: I am still able to execute other binaries (that dont use cygwin1.dll) as this user under IIS6. For instance to call rar.exe. -- 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: cygwin1.dll crash
I've tried what you said, cleaned my PATH var (using control panel, ...) but it doesn't work. still the same problem I ran a new IExporer window, to make sure it takes the new path values. I could do a full uninstall of cygwin, and install a clean one, but that looks so terrible;-( thks On Tue, 8 Feb 2005 15:48:41 -, Dave Korn [EMAIL PROTECTED] wrote: -Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 14:50 here you have the output for dir /w its quite huge Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 [.] [..] a2p.exe perl.dll perl.exe perl5.00503.exe perl95.exeperlglob.exe 6 File(s)987.136 bytes This is ActiveState perl, so I was wrong in my first guess. I'm still suspicious that it's the root cause of the trouble though; if any of the setup.exe post-install scripts rely on perl, they are liable to invoke active state perl instead of cygwin perl, and break when it fails to understand cygwin-style POSIX paths. I've put the cygwin path in top of my PATH var. but still the same problem Hmm, peculiar. May need some more thinking time over this. Precisely how did you set it? If you do it using the PATH command in a DOS prompt, that wouldn't affect a copy of setup.exe that you launched from explorer, you do need to set it in Start Menu / Settings / Control Panel / System / Advanced / Environment Variables. Try setting your PATH to nothing but these entries: C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem and see if that helps any. 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/ -- 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: perl winpid?
Reini Urban schrieb:
Gerrit P. Haase schrieb:
Yitzchak Scott-Thoennes wrote:
On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
Igor Pechtchanski schrieb:
On Sun, 6 Feb 2005, Reini Urban wrote:
I feel quite stupid now, but found nothing simple.
How to get the winpid from the current process in cygwin's perl?
We will check out there where this cygwin specific functionality
will go to.
Win32::Process::CygwinToWin32ProcessID() is my suggestion.
I'd rather see them in the Proc:: namespace, and I think it would make
sense to put them in perl's cygwin.c itself, if Gerrit is willing to
release yet another perl-5.8.6. If this sounds OK, I'll come up with
a patch.
I have no problem with another release. And I agree that such important
functions should go inside perl.
I've found the need functionality buried in Proc::ProcessTable.
Both pid's are populated for all windows processes.
$ perl -MProc::ProcessTable -e '$t = new Proc::ProcessTable;
map { print $_-fname, \t, $_-pid, \t, $_-winpid,\n; }
@{$t-table}'
/usr/bin/cygrunsrv 572 572
/usr/bin/cygrunsrv 840 840
C:\WINNT\Explorer.EXE 12201220
f:\cygnus\bin\perl.exe 22842284
f:\cygnus\bin\sh.exe27082708
f:\cygnus\bin\less.exe 29202920
f:\cygnus\bin\perl.exe 26082608
But the cygwin pid's seem to be wrong.
Some cygwin processes are not detected as such, so the pids are listed
as winpid's.
And fname is printed as windows path for those processes, though it
should be printed as cygwin path.
I'll complain upstream.
Then we won't have to pollute the Win32::Process namespace with this
cygwin-only functionality. And we don't have to wait for the still
unmaintained libwin32 upstream.
README.cygwin, cygwin/cygwin.c:
=item cygwin32_winpid_to_pid($pid)
Returns the windows process ID for the given cygwin pid. cygwin-only.
=item cygwin32_pid_to_winpid($pid)
Returns the cygwin process ID for the given windows pid. cygwin-only.
Or as seperate Proc::Cygwin package, which could be maintained at CPAN
and go to vendor_perl within gerrit's perl package?
Proc::Cygwin::Win32ProcessID($pid)
Proc::Cygwin::CygwinProcessID($winpid)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
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: Using PWD
Well, you got me all enthused, sigh :-(.
Which requires a path. The objective (here) is not to put the scripts on a
path because they are transient and using PATH would be overkill. So:
./my_script Which does indeed provide a path ('.'). But so
does dirname $0.
source scripts/my_scripts Which can't find my_scripts. `dirname $0`
returns 'bash', and as an added mystery if the code looks like:
echo $0
echo `dirname $0`
which -a my_script
the system also crashes my bash shell.
Oh well.
art
On Sun, 6 Feb 2005 09:20:53 -0800, wrote:
I'm trying to find the directory of an executing bash script and am having
very limited success. For example(s):
1. path/script.sh
2. source path/script.sh
3. bash path/script.sh
I can find the correct path only for the first example (dirname $0). PWD
(of course) only works when path == ./. The other two cases I can't seem
to get to work. Any idea how to get the path in examples 2 and 3?
art
Art,
unless I'm missing something you want
which -a your_script
zzapper (vim, cygwin, wiki zsh)
--
vim -c :%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg?
http://www.vim.org/tips/tip.php?tip_id=305 Best of Vim Tips
--
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: RXVT copy/paste behavior
On Tuesday, February 08, 2005 6:14 AM Rizwan Kassim wrote (sort of): I haven't been able to find out how to do the following: I'd like to accelerate my car using the left pedal and find some other way of stopping it (maybe the pedal on the right). Anyone know how to do this? Cheers, Rizwan It may be possible, but if you do it, don't be surprised when you crash and burn the first time you try to drive a different car. The selection model used by rxvt is standard throughout the X11 world. Learn it and enjoy the elegant simplicity of the scheme instead of the insane mouse, keyboard, mouse, keyboard routine that characterises the Windows way. Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.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: several more bugs found by coreutils
On Feb 2 11:07, Corinna Vinschen wrote:
On Feb 1 20:58, Erik Blake wrote:
Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
pwd.h defines struct passwd with the pw_uid and pw_gid members as ints,
although POSIX requires uid_t and gid_t.
http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
include/pwd.h is a newlib file. However, I was pretty happy that pw_uid
and pw_gid were defined as int, when we changed uids and gids from 16 to
32 bits. It was the one file which wasn't necessary to change.
We could just redefine struct passwd to use uid_t and gid_t, but this
would break (very very very very unlikely) builds of Cygwin using
sources of versions before 1.5.0. In other words, old Cygwin sources
using 16 bit uids/gids would go down hell.
Personally, I think I can live with that, but I would like to hear if
there's any good reason to build historic versions (say, b20) with a
recent newlib.
sys/time.h defines utimes with non-const second parameter, although POSIX
requires it to be const; likewise for utime in utime.h (deferred to
sys/utime.h). Additionally, both utimes() and utime() are required to
touch file ctime on success.
http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
[snip]
That should be easy to change in sys/time.h.
As far as the implementation of utime/utimes is affected, I already
changed it to set st_ctime.
I have attached a patch to newlib this time. Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions. So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Corinna
* libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
members to uid_t and gid_t according to SUSv3.
* libc/include/sys/time.h (utimes): Change second parameter
to const according to SUSv3.
Index: libc/include/pwd.h
===
RCS file: /cvs/src/src/newlib/libc/include/pwd.h,v
retrieving revision 1.2
diff -p -u -r1.2 pwd.h
--- libc/include/pwd.h 9 Mar 2003 21:08:51 - 1.2
+++ libc/include/pwd.h 8 Feb 2005 17:37:22 -
@@ -50,8 +50,8 @@ extern C {
struct passwd {
char*pw_name; /* user name */
char*pw_passwd; /* encrypted password */
- int pw_uid; /* user uid */
- int pw_gid; /* user gid */
+ uid_t pw_uid; /* user uid */
+ gid_t pw_gid; /* user gid */
char*pw_comment;/* comment */
char*pw_gecos; /* Honeywell login info */
char*pw_dir;/* home directory */
Index: libc/include/sys/time.h
===
RCS file: /cvs/src/src/newlib/libc/include/sys/time.h,v
retrieving revision 1.4
diff -p -u -r1.4 time.h
--- libc/include/sys/time.h 21 Apr 2001 03:22:47 - 1.4
+++ libc/include/sys/time.h 8 Feb 2005 17:37:22 -
@@ -72,7 +72,7 @@ struct itimerval {
int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z));
int _EXFUN(settimeofday, (const struct timeval *, const struct timezone *));
-int _EXFUN(utimes, (const char *__path, struct timeval *__tvp));
+int _EXFUN(utimes, (const char *__path, const struct timeval *__tvp));
int _EXFUN(getitimer, (int __which, struct itimerval *__value));
int _EXFUN(setitimer, (int __which, const struct itimerval *__value,
struct itimerval *__ovalue));
--
Corinna Vinschen
Cygwin Project Co-Leader
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: several more bugs found by coreutils
On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote: I have attached a patch to newlib this time. Thinking about that for a while, I'm pretty sure that it doesn't make sense to build old 32 bit versions of Cygwin with recent newlib versions. So I'm opting for having a clean pwd.h. The below patch changes the definitions of struct passwd and utimes(2) according to SUSv3. Cool. I was wondering about that. 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: several more bugs found by coreutils
On Feb 8 12:47, Christopher Faylor wrote: On Tue, Feb 08, 2005 at 06:42:11PM +0100, Corinna Vinschen wrote: I have attached a patch to newlib this time. Thinking about that for a while, I'm pretty sure that it doesn't make sense to build old 32 bit versions of Cygwin with recent newlib versions. So I'm opting for having a clean pwd.h. The below patch changes the definitions of struct passwd and utimes(2) according to SUSv3. Cool. I was wondering about that. It requires also a patch to Cygwin, but I'm waiting for Jeff's approval first. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com 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: Can't cd into directory
(Please reply to the mailing list, not me directly). acidblue wrote: - Original Message - From: Jonathan Arnold [EMAIL PROTECTED] To: acidblue [EMAIL PROTECTED] Cc: cygwin@cygwin.com Sent: Tuesday, February 08, 2005 7:26 AM Subject: Re: Can't cd into directory acidblue wrote: acidblue wrote on Tuesday, February 08, 2005 9:18 AM: I'm using the following syntax: cd '/cygdrive/c/Documents and Settings' I get a No such file or directory message. cygwin on WinXP installed to C:/ I get this message no matter which directory I try to cd into. Driving me nuts Please help. [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Tuesday, February 08, 2005 12:26 AM Subject: RE: Can't cd into directory Please post output of mount -p Sure thing: [EMAIL PROTECTED] ~ $ mount -p Prefix Type Flags /cygdrive system binmode [EMAIL PROTECTED] ~ $ You should probably double check the pages found here: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames in the Using Cygwin document. Probably you have a problem with the mount table. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin Ok I read the documents suggetsed and I am confused on how to mount my c drive. could some one give me the right syntax, 'cause 'mount -s /c and mount -s c:\ won't work Yes, those are not the correct commands. You need to tell it both the win32 path and the posix path: mount -s c:\\ /c Assuming you're using the bash shell, you need to escape the first '\' in the path. But normally, if you cygdrive is /, you should have this already. Again, check out the Problems report page, and try posting a new question, with all the necessary info. http://cygwin.com/problems.html -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Amazing Developments http://www.buddydog.org I feel like a fugitive from the law of averages. - William H. Mauldin -- 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: several more bugs found by coreutils
Corinna Vinschen wrote:
On Feb 2 11:07, Corinna Vinschen wrote:
On Feb 1 20:58, Erik Blake wrote:
Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
pwd.h defines struct passwd with the pw_uid and pw_gid members as ints,
although POSIX requires uid_t and gid_t.
http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
include/pwd.h is a newlib file. However, I was pretty happy that pw_uid
and pw_gid were defined as int, when we changed uids and gids from 16 to
32 bits. It was the one file which wasn't necessary to change.
We could just redefine struct passwd to use uid_t and gid_t, but this
would break (very very very very unlikely) builds of Cygwin using
sources of versions before 1.5.0. In other words, old Cygwin sources
using 16 bit uids/gids would go down hell.
Personally, I think I can live with that, but I would like to hear if
there's any good reason to build historic versions (say, b20) with a
recent newlib.
sys/time.h defines utimes with non-const second parameter, although POSIX requires it to
be const; likewise for utime in utime.h (deferred to sys/utime.h). Additionally,
both utimes() and utime() are required to touch file ctime on success.
http://www.opengroup.org/onlinepubs/009695399/functions/utimes.html
[snip]
That should be easy to change in sys/time.h.
As far as the implementation of utime/utimes is affected, I already
changed it to set st_ctime.
I have attached a patch to newlib this time. Thinking about that
for a while, I'm pretty sure that it doesn't make sense to build
old 32 bit versions of Cygwin with recent newlib versions. So I'm
opting for having a clean pwd.h.
The below patch changes the definitions of struct passwd and utimes(2)
according to SUSv3.
Looks fine. Please go ahead.
-- Jeff J.
Corinna
* libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid
members to uid_t and gid_t according to SUSv3.
* libc/include/sys/time.h (utimes): Change second parameter
to const according to SUSv3.
Index: libc/include/pwd.h
===
RCS file: /cvs/src/src/newlib/libc/include/pwd.h,v
retrieving revision 1.2
diff -p -u -r1.2 pwd.h
--- libc/include/pwd.h 9 Mar 2003 21:08:51 - 1.2
+++ libc/include/pwd.h 8 Feb 2005 17:37:22 -
@@ -50,8 +50,8 @@ extern C {
struct passwd {
char *pw_name; /* user name */
char *pw_passwd; /* encrypted password */
- int pw_uid; /* user uid */
- int pw_gid; /* user gid */
+ uid_t pw_uid; /* user uid */
+ gid_t pw_gid; /* user gid */
char *pw_comment; /* comment */
char *pw_gecos; /* Honeywell login info */
char *pw_dir; /* home directory */
Index: libc/include/sys/time.h
===
RCS file: /cvs/src/src/newlib/libc/include/sys/time.h,v
retrieving revision 1.4
diff -p -u -r1.4 time.h
--- libc/include/sys/time.h 21 Apr 2001 03:22:47 - 1.4
+++ libc/include/sys/time.h 8 Feb 2005 17:37:22 -
@@ -72,7 +72,7 @@ struct itimerval {
int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z));
int _EXFUN(settimeofday, (const struct timeval *, const struct timezone *));
-int _EXFUN(utimes, (const char *__path, struct timeval *__tvp));
+int _EXFUN(utimes, (const char *__path, const struct timeval *__tvp));
int _EXFUN(getitimer, (int __which, struct itimerval *__value));
int _EXFUN(setitimer, (int __which, const struct itimerval *__value,
struct itimerval *__ovalue));
--
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: RXVT copy/paste behavior
-Original Message- From: cygwin-owner On Behalf Of Phil Betts Sent: 08 February 2005 17:09 The selection model used by rxvt is standard throughout the X11 world. It's insane. Unless you have the precision muscular control skills of a world-class gymnast, a mouse always moves at least a little bit when you press down on the button. This makes it very tricky to select a new window without unintentionally erasing the contents of the clipboard that you were hoping to paste there because the mouse moved just enough as you clicked it to select a single character and the auto-copy destroyed your clipboard contents without asking. Destroying user data without any kind of confirmation, are-you-sure, or requiring a difficult-to-type-accidentally key-combination (such as ctrl-c) is an appallingly incompetent piece of UI design. It's like having a pistol without a safety catch, or an ICBM without a dual-key control. FWIW, it's not just X programs that do this. TeraTerm (a 'doze terminal emulator) has this same behaviour, and it has wasted lots of my time and energy in having to repeatedly go back to the original window and re-copy the original text. And don't tell me that I'm only ever allowed to select windows by clicking on the menu bar and that I get what I deserve if I click in the main part of the window. If you have lots of windows open, the menu bars of many of them are often obscured. Why should 99% of the window's surface area be verboten for selecting that window? The entire model is screwy. It wastes lots of my time and interrupts my workflow. The 'doze way works smoothly and is much closer to fail-safe: it's very hard to accidentally press Ctrl+C and lose data in the same way. Learn it and enjoy the elegant simplicity of the scheme instead of the insane mouse, keyboard, mouse, keyboard routine that characterises the Windows way. Real experts operate a computer with one hand on the mouse and one on the keyboard *at the same time* anyway. This makes it very easy to do selecting, cutting and pasting. And under 'doze, you can also use a right-click over the selected area to bring up a menu with cut, copy and paste options. You don't *have* to use the keyboard if you don't find it more efficient. 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/
Problem with alarm() not functioning twice in one program.
The following program produces the output:
Begin
Done
Begin
...and then hangs.
Can anyone help me understand why?
Thankyou,
Max.
#include stdio.h
#include signal.h
#include setjmp.h
#include unistd.h
jmp_buf timer;
void alarm_handler(int dummy)
{
longjmp(timer, 1);
}
void speedtest(void)
{
fprintf(stderr, Begin\n);
signal(SIGALRM, alarm_handler);
if (setjmp(timer) == 0) {
alarm(1);
while(1) {};
}
signal(SIGALRM, SIG_DFL);
fprintf(stderr, Done\n);
return;
}
int main(int argc, char* argv[])
{
speedtest();
speedtest();
return 0;
}
--
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: Problem with alarm() not functioning twice in one program.
On Tue, 8 Feb 2005, Max Bowsher wrote: The following program produces the output: Begin Done Begin ...and then hangs. Can anyone help me understand why? http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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: Problem with alarm() not functioning twice in one program.
Brian Ford wrote: On Tue, 8 Feb 2005, Max Bowsher wrote: The following program produces the output: Begin Done Begin ...and then hangs. Can anyone help me understand why? http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html Ah, OK. So are you saying SIGALRM has been entered, but has not returned, so the signal handling code won't try to enter it again ? That makes sense, I'll see if I can get the problem piece of code fixed. Max. -- 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/
Changing root path from /ecos-c/ to /
Hi, I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /. When I type mount in cygwin, I get the following: C:\PFARM\cygwin on / type system (binmode) c: on /ecos-c type user (textmode) c: on / type user (textmode) e: on /cygdrive/e type user (textmode,noumount) f: on /cygdrive/f type user (textmode,noumount) h: on /cygdrive/h type user (textmode,noumount) i: on /cygdrive/i type user (textmode,noumount) C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode The utility I'm using fails unless C: on the Windows box is mounted as '/'. Any suggestions? Shane. p.s. Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest matching prefix in the mount table. Thus, if C: is mounted as /c and also as /, then Cygwin would translate C:/foo/bar to /c/foo/bar. (http://www.cygwin.com/cygwin-ug-net/using.html#mount-table) -- 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: several more bugs found by coreutils
On Feb 8 14:17, Jeff Johnston wrote: Corinna Vinschen wrote: I have attached a patch to newlib this time. Thinking about that for a while, I'm pretty sure that it doesn't make sense to build old 32 bit versions of Cygwin with recent newlib versions. So I'm opting for having a clean pwd.h. The below patch changes the definitions of struct passwd and utimes(2) according to SUSv3. Looks fine. Please go ahead. -- Jeff J. Corinna * libc/include/pwd.h (struct passwd): Change pw_uid and pw_gid members to uid_t and gid_t according to SUSv3. * libc/include/sys/time.h (utimes): Change second parameter to const according to SUSv3. Thanks, applied. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com 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: Problem with alarm() not functioning twice in one program.
On Tue, 8 Feb 2005, Max Bowsher wrote: Brian Ford wrote: On Tue, 8 Feb 2005, Max Bowsher wrote: The following program produces the output: Begin Done Begin ...and then hangs. Can anyone help me understand why? http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html Ah, OK. So are you saying SIGALRM has been entered, but has not returned, so the signal handling code won't try to enter it again ? SIGALRM has been blocked upon entry to the signal handling routine. Since you long jumped out of it, it's still blocked. Did you follow that thread through to the end? Maybe I should have quoted this instead: http://www.cygwin.com/ml/cygwin/2004-10/msg00606.html -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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: RXVT copy/paste behavior
Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Phil Betts Sent: 08 February 2005 17:09 It's insane. not really -- works exceptionally well for me, much better than keyboard shortcuts for my use. Unless you have the precision muscular control skills of a world-class gymnast, a mouse always moves at least a little bit when you press down on the button. I never considered my muscular control as such - but evidently I should try out for the next olympics This makes it very tricky to select a new window without unintentionally erasing the contents of the clipboard that you were hoping to paste there because the mouse moved just enough as you clicked it to select a single character and the auto-copy destroyed your clipboard contents without asking. I cannot remember the last time this happened to me... i.e. extremely rare for this to occur. The entire model is screwy. It wastes lots of my time and interrupts my workflow. The 'doze way works smoothly and is much closer to fail-safe: it's very hard to accidentally press Ctrl+C and lose data in the same way. not true, considering that the c and v keys sit side by side on the keyboard. if the sequence copy with left mouse button, select new window with left mouse button, paste into new window with middle mouse button/scroll wheel causes you problems... try copy with left mouse button, select_and_paste at same time into new window via middle mouse button/scroll wheel. reid -- 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: Problem with alarm() not functioning twice in one program.
Brian Ford wrote: On Tue, 8 Feb 2005, Max Bowsher wrote: Brian Ford wrote: On Tue, 8 Feb 2005, Max Bowsher wrote: The following program produces the output: Begin Done Begin ...and then hangs. Can anyone help me understand why? http://www.cygwin.com/ml/cygwin/2004-10/msg00598.html Ah, OK. So are you saying SIGALRM has been entered, but has not returned, so the signal handling code won't try to enter it again ? SIGALRM has been blocked upon entry to the signal handling routine. Since you long jumped out of it, it's still blocked. Did you follow that thread through to the end? No, I assumed you were pointing to a specific message. Maybe I should have quoted this instead: http://www.cygwin.com/ml/cygwin/2004-10/msg00606.html Very helpful, thanks. Max. -- 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: RXVT copy/paste behavior
Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Phil Betts Sent: 08 February 2005 17:09 The selection model used by rxvt is standard throughout the X11 world. http://seth.positivism.org/man.cgi/rxvt there are hyperlinks in the above page that reference how the selection style is configured... selectstyle: mode Set mouse selection style to old which is 2.20, oldword which is xterm style with 2.20 old word selection, or anything else which gives xterm style selection. reid -- 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/
bug in setup.exe?
I've run into the following situation on several machines now, at multiple times -- each with different versions of cygwin (so I'm not following the bug reporting procedure as I think the version information provided by cygcheck isn't really relevant and as I'm currently in a non-cygwin-working state as a result of this issue). Frequently, when running setup.exe and specifying that all packages should be installed (the mode I almost always use), setup.exe bombs while uninstalling a package that it knows it needs to update with the error that cygwin1.dll is not found. Indeed, at the point the dialog box comes up telling me that cygwin1.dll wasn't found, if I check, it has indeed been deleted from my /bin directory (actually d:\cygwin\bin). I suspect this is because setup has determined that it needs to upgrade my cygwin1.dll, and therefore must uninstall the old one first and then install the new one. The problem is, that either setup itself (doubtful) or one or more of the uninstall/install scripts needs cygwin1.dll in order to run successfully. Can anyone in the know tell me how this is supposed to work? I tried searching the mailing lists, but the cygwin site says that searching was disabled due to your recent disk crash. I tried searching on google and only found one relevant reference (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that page didn't lead me to any responses. If you press the ok button on the dialog telling you that cygwin1.dll was not found, setup proceeds with the next package. Frequently, I have to press OK many times (depending on the packages needing to be installed, of course) in order to get to the end of setup. Sometimes I can get through with a successfull uninstall/install of the necessary packages and cygwin1.dll does get installed again. But the packages whose uninstall/install depended on cygwin1.dll, of course, were not actually correctly uninstalled or installed. Ideas? -- Eric -- 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: tee piping to head gives error message
Buchbinder, Barry (NIH/NIAID BBuchbinder at niaid.nih.gov writes:
Given that the purpose of head is to print the first few lines of a
file, it kind of makes sense to me that it would close the file after
it's read them rather than keeping the input file open and manually
reading-and-discarding the entire rest of it for no good reason.
Agreed.
So I reckon this is as-expected and by-design behaviour.
I might put it as as-designed rather than by-design. And for me, it
certainly was unexpected. tee and head are both part of coreutils. I would
expect that all coreutils would behave the same for head closing the pipe,
but they don't. And I would also expect that all utilities in a package
that includes a utility that breaks pipes as a normal course of its
operation would be silent when the two utilities are used together. I would
expect that tee pipes to head more often than something nasty happens and a
pipe just breaks.
Coreutils is following POSIX, and the behavior of pipes is by design within
POSIX. POSIX requires that a failed write into a pipe raises SIGPIPE, and that
the default action on SIGPIPE is to terminate the process. Note that
termination bypasses exit handlers registered with atexit(). POSIX also allows
an application to ignore SIGPIPE; at which point it will detect failures in
writing to a broken pipe but can continue in normal operation. Furthermore,
all of the coreutils are designed to check, using atexit() handlers, for any
failed write to stdout.
Normally, tee and most other coreutils do nothing special with SIGPIPE, which
means they only ignore SIGPIPE if their parent process was ignoring it. So my
guess is that somewhere in your shell you are setting up your environment to
ignore SIGPIPE, so that applications spawned by your shell see write failures
to broken pipes rather than the default of early termination.
Study this example, in bash, for more insight into child behavior when SIGPIPE
is ignored or not:
$ trap - PIPE # restore default handling to SIGPIPE
$ yes | tee /dev/null | head /dev/null
$ echo ${PIPESTATUS[*]}
141 141 0 # yes and tee had SIGPIPE, head was successful
$ seq 1 | tee foo | head /dev/null
$ echo ${PIPESTATUS[*]}
141 141 0 # yes and tee had SIGPIPE, head was successful
$ wc foo
2474 2475 11264 foo # foo did not get the complete output of seq
$ trap '' PIPE # now ignore SIGPIPE
$ seq 1000 | tee /dev/null | head /dev/null
$ echo ${PIPESTATUS[*]}
0 0 0 # all 3 programs were successful
$ seq 1 | tee foo | head /dev/null
tee: standard output: Broken pipe
tee: write error
$ echo ${PIPESTATUS[*]}
0 1 0 # seq and head were successful, tee noticed the broken pipe
$ wc foo
1 1 48894 foo # foo got the complete output of seq
$ yes | tee /dev/null | head /dev/null
tee: standard output: Broken pipe
# At this point, yes and tee are in an infinite loop, hit ctrl-c
$ echo ${PIPESTATUS[*]}
130 130 0 # yes and tee had SIGINT from ctrl-c, head was successful
$ yes | tee -i /dev/null | head /dev/null
tee: standard output: Broken pipe
# Again, an infloop, hit ctrl-c
$ echo ${PIPESTATUS[*]}
130 1 0 # yes had SIGINT, tee just regular failure from broken pipe
This seems like something the coreutils maintainer might want to address
with the upstream maintainers, or to patch himself. (I won't complain if he
doesn't patch it.
Nope - as the cygwin coreutils maintainer, I won't patch coreutils, because the
problem of an error message from writing to a broken pipe is not unique to
cygwin (I ran the same tests on coreutils 5.3.0 on Solaris and saw similar
behavior). However, note that tee currently has the POSIX-mandated -i option
to ignore SIGINT, where in prior versions of coreutils it was treating -i as
ignoring all signals; the change in 5.3.0 for tee to terminate on SIGPIPE was
intentional, added around April 2004 (see /usr/share/doc/coreutils-5.3.0/NEWS,
or http://lists.gnu.org/archive/html/bug-coreutils/2004-04/msg00126.html). You
may have success if you propose upstream on the coreutils mailing list the
addition of a new option to ignore SIGPIPE to allow the restoration of prior
behavior while still complying with POSIX. You may also want to ask for an
interpretation from the POSIX folks as to whether write errors to stdout must
force tee to fail, or if the current wording that tee return 0 only if The
standard input was successfully copied to all output files allows success even
if writes to stdout failed, basing your argument on the fact that stdout is not
one of the output files on the command line.
http://www.opengroup.org/onlinepubs/009695399/utilities/tee.html
If, as Dave Korn's followup pointed out, cygwin is hanging on some instances of
pipe handling and process termination interaction, then that is a cygwin and
not a coreutils bug, and I wouldn't know what to do to try to patch that.
Taking on coreutils was quite a
[PATCH] Re: perl winpid?
On Tue, Feb 08, 2005 at 03:48:01PM +0100, Reini Urban wrote:
Gerrit P. Haase schrieb:
Yitzchak Scott-Thoennes wrote:
On Mon, Feb 07, 2005 at 02:17:32PM +0100, Reini Urban wrote:
Igor Pechtchanski schrieb:
On Sun, 6 Feb 2005, Reini Urban wrote:
I feel quite stupid now, but found nothing simple.
How to get the winpid from the current process in cygwin's perl?
We will check out there where this cygwin specific functionality
will go to.
Win32::Process::CygwinToWin32ProcessID() is my suggestion.
I'd rather see them in the Proc:: namespace, and I think it would make
sense to put them in perl's cygwin.c itself, if Gerrit is willing to
release yet another perl-5.8.6. If this sounds OK, I'll come up with
a patch.
I have no problem with another release. And I agree that such important
functions should go inside perl.
Ok.
Then we won't have to pollute the Win32::Process namespace with this
cygwin-only functionality. And we don't have to wait for the still
unmaintained libwin32 upstream.
README.cygwin, cygwin/cygwin.c:
=item cygwin32_winpid_to_pid($pid)
Returns the windows process ID for the given cygwin pid. cygwin-only.
=item cygwin32_pid_to_winpid($pid)
Returns the cygwin process ID for the given windows pid. cygwin-only.
How does this look?
--- README.cygwin.orig 2003-08-19 07:37:00.0 -0700
+++ README.cygwin 2005-02-08 11:47:03.38288 -0800
@@ -369,6 +369,8 @@
See comment on fork in LMiscellaneous below.
+=head1 Specific features of the Cygwin port
+
=head2 Script Portability on Cygwin
Cygwin does an outstanding job of providing UNIX-like semantics on top of
@@ -470,6 +472,25 @@
=back
+=head2 Prebuilt methods:
+
+=over 4
+
+=item CCwd::cwd
+
+Returns current working directory.
+
+=item CProc::Cygwin::cygwin32_pid_to_winpid
+
+Translates a cygwin pid to the corresponding Windows pid (which may or
+may not be the same).
+
+=item CProc::Cygwin::cygwin32_winpid_to_pid
+
+Translates a Windows pid to the corresponding cygwin pid (if any).
+
+=back
+
=head1 INSTALL PERL ON CYGWIN
This will install Perl, including Iman pages.
--- perl/cygwin/cygwin.c.orig 2002-03-20 15:02:25.0 -0800
+++ perl/cygwin/cygwin.c2005-02-08 12:37:48.601689600 -0800
@@ -9,6 +9,7 @@
#include unistd.h
#include process.h
+#include sys/cygwin.h
/*
* pp_system() implemented via spawn()
@@ -155,6 +156,39 @@
XSRETURN_UNDEF;
}
+static
+XS(XS_Proc_Cygwin_cygwin32_pid_to_winpid)
+{
+dXSARGS;
+if (items != 1)
+Perl_croak(aTHX_ Usage: Proc::Cygwin::cygwin32_pid_to_winpid(pid));
+pid_t pid = (pid_t)SvIV(ST(0));
+pid_t RETVAL;
+dXSTARG;
+if ((RETVAL = cygwin_internal(CW_CYGWIN_PID_TO_WINPID, pid)) 0) {
+ XSprePUSH; PUSHi((IV)RETVAL);
+XSRETURN(1);
+}
+XSRETURN_UNDEF;
+}
+
+static
+XS(XS_Proc_Cygwin_cygwin32_winpid_to_pid)
+{
+dXSARGS;
+if (items != 1)
+Perl_croak(aTHX_ Usage: Proc::Cygwin::cygwin32_winpid_to_pid(pid));
+pid_t pid = (pid_t)SvIV(ST(0));
+pid_t RETVAL;
+dXSTARG;
+if ((RETVAL = cygwin32_winpid_to_pid(pid)) 0) {
+XSprePUSH; PUSHi((IV)RETVAL);
+XSRETURN(1);
+}
+XSRETURN_UNDEF;
+}
+
+
void
init_os_extras(void)
{
@@ -162,4 +196,8 @@
dTHX;
newXS(Cwd::cwd, Cygwin_cwd, file);
+newXS(Proc::Cygwin::cygwin32_winpid_to_pid,
+ XS_Proc_Cygwin_cygwin32_winpid_to_pid, file);
+newXS(Proc::Cygwin::cygwin32_pid_to_winpid,
+ XS_Proc_Cygwin_cygwin32_pid_to_winpid, file);
}
--- perl/MANIFEST.orig 2005-02-01 04:17:14.0 -0800
+++ perl/MANIFEST 2005-02-08 13:35:30.299366400 -0800
@@ -2493,6 +2493,7 @@
t/lib/1_compile.t See if the various libraries and extensions
compile
t/lib/commonsense.tSee if configuration meets basic needs
t/lib/compmod.pl Helper for 1_compile.t
+t/lib/cygwin.t Builtin cygwin function tests
t/lib/Devel/switchd.pm Module for t/run/switchd.t
t/lib/Dev/Null.pm Module for testing Test::Harness
t/lib/dprof/test1_tPerl code profiler tests
--- perlpatch/t/lib/cygwin.t1970-01-01 00:00:00.0 +
+++ perl/t/lib/cygwin.t 2005-02-08 21:33:53.319916800 +
@@ -0,0 +1,33 @@
+#!perl
+
+BEGIN {
+chdir 't' if -d 't';
+@INC = ('../lib');
+unless ($^O eq cygwin) {
+ print 1..0 # skipped: cygwin specific test\n;
+ exit 0;
+}
+}
+
+use Test::More tests = 4;
+
+is(Proc::Cygwin::cygwin32_winpid_to_pid(
+ Proc::Cygwin::cygwin32_pid_to_winpid($$)),
+ $$, perl pid translates to itself);
+
+my $parent = getppid;
+SKIP: {
+skip test not run from cygwin process, 1 if $parent = 1;
+is(Proc::Cygwin::cygwin32_winpid_to_pid(
+ Proc::Cygwin::cygwin32_pid_to_winpid($parent)),
+ $parent, parent pid translates to itself);
+}
+
+my $catpid = open my $cat, |cat or die Couldn't cat: $!;
+open my $ps, ps| or die Couldn't do ps: $!;
+my
RE: RXVT copy/paste behavior
copy with left mouse button, select_and_paste at same time into new window via middle mouse button/scroll wheel. or, copy with left mouse button, select new window with right mouse button(rather than left), paste with middle button/scroller reid -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [PATCH] Re: perl winpid?
On Tue, Feb 08, 2005 at 01:46:41PM -0800, Yitzchak Scott-Thoennes wrote: How does this look? --- README.cygwin.orig2003-08-19 07:37:00.0 -0700 +++ README.cygwin 2005-02-08 11:47:03.38288 -0800 Sorry for the inconsistent directory levels; those should have been perl/README.cygwin... -- 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/
Setting the Windows Path variable for children of a bash script....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy all,
I've searched through the archives on this, but I've come up empty, so
I figured I'd ask
I'm trying to execute a cygwin-ignorant Windows binary from a bash
script. However, the DLLs required to load this binary are not in the
system- or user-wide Windows Path variable (nor do I want them to be).
I'm trying to modify the environment before execution of this binary,
but it doesn't seem to work. Here's what I've got:
# ...
Path=$(cygpath -pw ${PATH});$(cygpath -pw ${LD_LIBRARY_PATH})
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to
binary.exe reside. Unfortunately, binary.exe doesn't seem to be able to
find them there when being invoked from the script's exec command.
Before someone suggests the obvious, I am using Cygwin and bash (etc.)
as a test harness for a binary I'm writing. I may test several
different versions of the binary on the same machine. The DLLs cannot
reside in c:\windows\..., nor can they reside in the same directory as
binary.exe because binary.exe is actually c:\Python24\python.exe and
the DLLs are from different versions of a third-party SDK that I'm
accessing via swig/python. In short, I need to be able to override
where the DLLs are found by the cygwin-ignorant version of Python in a
shell script on an ad hoc basis.
Please don't tell me to use Cygwin's python either, since I have to
test the Windows version using the same test harness.
Does anyone know how to do this? Any help is much appreciated.
-- Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCUCMnLpDzL5I7l8RAu0hAJwKF4C/6vyb/lJNLc8Ml5lDj/tRawCeIxrb
xVavIVr4YXHG29NeTJZdnSQ=
=yoUB
-END PGP SIGNATURE-
--
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: Setting the Windows Path variable for children of a bash script....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Incidentally, I have already thought of doing something like this:
# ...
Path=$(cygpath -pw ${PATH});$(cygpath -pw ${LD_LIBRARY_PATH})
export Path
exec ${0}.bat ${Path} ${1+[EMAIL PROTECTED]}
Where ${0}.bat may be something like:
set Path=%1
shift
%1 %2 %3 ...
But this does not work, since some of my arguments may contain spaces
(which are not parsed correctly in the batch file), and batch files
have an unusable limit on the number of useful arguments they can parse
(%* is *not* affected by the shift batch file command, nor does it
properly quote arguments). Using %1 %2 %3 ... does not help
either.
In short, I do not believe that batch files are a viable solution to my
problem (though this may stem from my ignorance on how to write them
robustly). Either way, I would like to find an alternate solution.
-- Matt
On Feb 8, 2005, at 14:43, Matthew Bogosian wrote:
...
I'm trying to execute a cygwin-ignorant Windows binary from a bash
script. However, the DLLs required to load this binary are not in the
system- or user-wide Windows Path variable (nor do I want them to be).
I'm trying to modify the environment before execution of this binary,
but it doesn't seem to work. Here's what I've got:
# ...
Path=$(cygpath -pw ${PATH});$(cygpath -pw ${LD_LIBRARY_PATH})
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to
binary.exe reside. Unfortunately, binary.exe doesn't seem to be able
to find them there when being invoked from the script's exec command.
...
Does anyone know how to do this? Any help is much appreciated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCUMunLpDzL5I7l8RAv8PAKCRGQEebvZVYrlwziw2fNB9m/qfQACeP1me
VIpvbTm0cpnlYa+m3YDy+Zo=
=fRSK
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: bug in setup.exe?
On Tue, 8 Feb 2005, Swenson, Eric wrote: I've run into the following situation on several machines now, at multiple times -- each with different versions of cygwin (so I'm not following the bug reporting procedure as I think the version information provided by cygcheck isn't really relevant and as I'm currently in a non-cygwin-working state as a result of this issue). Frequently, when running setup.exe and specifying that all packages should be installed (the mode I almost always use), setup.exe bombs while uninstalling a package that it knows it needs to update with the error that cygwin1.dll is not found. Indeed, at the point the dialog box comes up telling me that cygwin1.dll wasn't found, if I check, it has indeed been deleted from my /bin directory (actually d:\cygwin\bin). I suspect this is because setup has determined that it needs to upgrade my cygwin1.dll, and therefore must uninstall the old one first and then install the new one. The problem is, that either setup itself (doubtful) or one or more of the uninstall/install scripts needs cygwin1.dll in order to run successfully. Can anyone in the know tell me how this is supposed to work? This is indeed a (known, long-standing) bug in setup.exe. The problem is that some packages have pre-remove scripts that prepare a package for removal. These scripts are run when the packages are removed, which happens in alphabetical order of package names, so the scripts will bomb out if their packages happen to follow the cygwin package alphabetically. It's clear that one needs to run all pre-remove scripts before removing the actual package files. It's also clear that the alphabetical package name order is the wrong order to run pre-remove scripts in. What is not clear is what the right order is. http://cygwin.com/acronyms/#PTC. :-) I tried searching the mailing lists, but the cygwin site says that searching was disabled due to your recent disk crash. I tried searching on google and only found one relevant reference (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that page didn't lead me to any responses. If you press the ok button on the dialog telling you that cygwin1.dll was not found, setup proceeds with the next package. Frequently, I have to press OK many times (depending on the packages needing to be installed, of course) in order to get to the end of setup. Sometimes I can get through with a successfull uninstall/install of the necessary packages and cygwin1.dll does get installed again. But the packages whose uninstall/install depended on cygwin1.dll, of course, were not actually correctly uninstalled or installed. Ideas? -- Eric One possible idea is to find out which packages have pre-remove scripts (run find /etc/preremove -type f | xargs cygcheck -f | sort -u to find those) and upgrade them before upgrading everything else. This, of course, carries other problems with it (i.e., the postinstall scripts may need the new versions of cygwin1.dll, etc). Ultimately, this needs to be fixed in setup.exe (once we figure out the right way of doing it). There was some discussion of this in the cygwin-apps archives (search for preremove, I 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Changing root path from /ecos-c/ to /
At 12:20 AM 2/7/2005, you wrote: Hi, I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /. When I type mount in cygwin, I get the following: C:\PFARM\cygwin on / type system (binmode) c: on /ecos-c type user (textmode) c: on / type user (textmode) e: on /cygdrive/e type user (textmode,noumount) f: on /cygdrive/f type user (textmode,noumount) h: on /cygdrive/h type user (textmode,noumount) i: on /cygdrive/i type user (textmode,noumount) C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode The utility I'm using fails unless C: on the Windows box is mounted as '/'. Any suggestions? Shane. p.s. Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest matching prefix in the mount table. Thus, if C: is mounted as /c and also as /, then Cygwin would translate C:/foo/bar to /c/foo/bar. (http://www.cygwin.com/cygwin-ug-net/using.html#mount-table) Seems like you're answering your own question. Try 'umount -f /ecos-c'. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Setting the Windows Path variable for children of a bash script....
On Tue, 8 Feb 2005, Matthew Bogosian wrote:
Howdy all,
I've searched through the archives on this, but I've come up empty, so I
figured I'd ask
I'm trying to execute a cygwin-ignorant Windows binary from a bash script.
However, the DLLs required to load this binary are not in the system- or
user-wide Windows Path variable (nor do I want them to be). I'm trying to
modify the environment before execution of this binary, but it doesn't seem to
work. Here's what I've got:
# ...
Path=$(cygpath -pw ${PATH});$(cygpath -pw ${LD_LIBRARY_PATH})
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to binary.exe
reside. Unfortunately, binary.exe doesn't seem to be able to find them there
when being invoked from the script's exec command.
Before someone suggests the obvious, I am using Cygwin and bash (etc.) as a
test harness for a binary I'm writing. I may test several different versions
of the binary on the same machine. The DLLs cannot reside in c:\windows\...,
nor can they reside in the same directory as binary.exe because binary.exe is
actually c:\Python24\python.exe and the DLLs are from different versions of a
third-party SDK that I'm accessing via swig/python. In short, I need to be
able to override where the DLLs are found by the cygwin-ignorant version of
Python in a shell script on an ad hoc basis.
Please don't tell me to use Cygwin's python either, since I have to test the
Windows version using the same test harness.
Does anyone know how to do this? Any help is much appreciated.
PATH=${PATH}:${LD_LIBRARY_PATH}
export PATH
exec /cygdrive/c/path/to/windows/binary.exe
The PATH variable is treated specially by Cygwin and is translated from
POSIX path format to Windows path format when calling Windows programs.
In your first case it was doing the translation twice, so C:\WINDOWS
became C;C:\WINDOWS.
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!
The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: bug in setup.exe?
Thanks, Igor. Would another possible solution be to have setup special case *only* the cygwin-dll package? Have it run all the pre-remove scripts first, then if the cygwin-dll package needs updating, do that, and then do the rest? Then, packages that have a dependency on cygwin1.dll in their scripts can be marked as needing to be run before (or after for post-remove) the cygwin-dll update. Then, the actual ordering algorithm is simply: run pre-remove scripts, remove cygwin.dll, install new cygwin.dll, and then run post-remove scripts. -- Eric -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 2:59 PM To: Swenson, Eric Cc: cygwin@cygwin.com Subject: Re: bug in setup.exe? On Tue, 8 Feb 2005, Swenson, Eric wrote: I've run into the following situation on several machines now, at multiple times -- each with different versions of cygwin (so I'm not following the bug reporting procedure as I think the version information provided by cygcheck isn't really relevant and as I'm currently in a non-cygwin-working state as a result of this issue). Frequently, when running setup.exe and specifying that all packages should be installed (the mode I almost always use), setup.exe bombs while uninstalling a package that it knows it needs to update with the error that cygwin1.dll is not found. Indeed, at the point the dialog box comes up telling me that cygwin1.dll wasn't found, if I check, it has indeed been deleted from my /bin directory (actually d:\cygwin\bin). I suspect this is because setup has determined that it needs to upgrade my cygwin1.dll, and therefore must uninstall the old one first and then install the new one. The problem is, that either setup itself (doubtful) or one or more of the uninstall/install scripts needs cygwin1.dll in order to run successfully. Can anyone in the know tell me how this is supposed to work? This is indeed a (known, long-standing) bug in setup.exe. The problem is that some packages have pre-remove scripts that prepare a package for removal. These scripts are run when the packages are removed, which happens in alphabetical order of package names, so the scripts will bomb out if their packages happen to follow the cygwin package alphabetically. It's clear that one needs to run all pre-remove scripts before removing the actual package files. It's also clear that the alphabetical package name order is the wrong order to run pre-remove scripts in. What is not clear is what the right order is. http://cygwin.com/acronyms/#PTC. :-) I tried searching the mailing lists, but the cygwin site says that searching was disabled due to your recent disk crash. I tried searching on google and only found one relevant reference (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that page didn't lead me to any responses. If you press the ok button on the dialog telling you that cygwin1.dll was not found, setup proceeds with the next package. Frequently, I have to press OK many times (depending on the packages needing to be installed, of course) in order to get to the end of setup. Sometimes I can get through with a successfull uninstall/install of the necessary packages and cygwin1.dll does get installed again. But the packages whose uninstall/install depended on cygwin1.dll, of course, were not actually correctly uninstalled or installed. Ideas? -- Eric One possible idea is to find out which packages have pre-remove scripts (run find /etc/preremove -type f | xargs cygcheck -f | sort -u to find those) and upgrade them before upgrading everything else. This, of course, carries other problems with it (i.e., the postinstall scripts may need the new versions of cygwin1.dll, etc). Ultimately, this needs to be fixed in setup.exe (once we figure out the right way of doing it). There was some discussion of this in the cygwin-apps archives (search for preremove, I 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: bug in setup.exe?
Eric, Please make sure your mailer honors the Reply-To: field. I set it for a reason. Thanks. I've also reformatted your top-posted message. Top-posting is rather annoying -- if you can possibly avoid it, please do. On Tue, 8 Feb 2005, Swenson, Eric wrote: -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 2:59 PM To: Swenson, Eric Cc: [EMAIL PROTECTED] http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. Subject: Re: bug in setup.exe? On Tue, 8 Feb 2005, Swenson, Eric wrote: I've run into the following situation on several machines now, at multiple times -- each with different versions of cygwin (so I'm not following the bug reporting procedure as I think the version information provided by cygcheck isn't really relevant and as I'm currently in a non-cygwin-working state as a result of this issue). Frequently, when running setup.exe and specifying that all packages should be installed (the mode I almost always use), setup.exe bombs while uninstalling a package that it knows it needs to update with the error that cygwin1.dll is not found. Indeed, at the point the dialog box comes up telling me that cygwin1.dll wasn't found, if I check, it has indeed been deleted from my /bin directory (actually d:\cygwin\bin). I suspect this is because setup has determined that it needs to upgrade my cygwin1.dll, and therefore must uninstall the old one first and then install the new one. The problem is, that either setup itself (doubtful) or one or more of the uninstall/install scripts needs cygwin1.dll in order to run successfully. Can anyone in the know tell me how this is supposed to work? This is indeed a (known, long-standing) bug in setup.exe. The problem is that some packages have pre-remove scripts that prepare a package for removal. These scripts are run when the packages are removed, which happens in alphabetical order of package names, so the scripts will bomb out if their packages happen to follow the cygwin package alphabetically. It's clear that one needs to run all pre-remove scripts before removing the actual package files. It's also clear that the alphabetical package name order is the wrong order to run pre-remove scripts in. What is not clear is what the right order is. http://cygwin.com/acronyms/#PTC. :-) I tried searching the mailing lists, but the cygwin site says that searching was disabled due to your recent disk crash. I tried searching on google and only found one relevant reference (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that page didn't lead me to any responses. If you press the ok button on the dialog telling you that cygwin1.dll was not found, setup proceeds with the next package. Frequently, I have to press OK many times (depending on the packages needing to be installed, of course) in order to get to the end of setup. Sometimes I can get through with a successfull uninstall/install of the necessary packages and cygwin1.dll does get installed again. But the packages whose uninstall/install depended on cygwin1.dll, of course, were not actually correctly uninstalled or installed. Ideas? -- Eric One possible idea is to find out which packages have pre-remove scripts (run find /etc/preremove -type f | xargs cygcheck -f | sort -u to find those) and upgrade them before upgrading everything else. This, of course, carries other problems with it (i.e., the postinstall scripts may need the new versions of cygwin1.dll, etc). Ultimately, this needs to be fixed in setup.exe (once we figure out the right way of doing it). There was some discussion of this in the cygwin-apps archives (search for preremove, I think). Igor Thanks, Igor. Would another possible solution be to have setup special case *only* the cygwin-dll package? Have it run all the pre-remove scripts first, then if the cygwin-dll package needs updating, do that, and then do the rest? Then, packages that have a dependency on cygwin1.dll in their scripts can be marked as needing to be run before (or after for post-remove) the cygwin-dll update. Then, the actual ordering algorithm is simply: run pre-remove scripts, remove cygwin.dll, install new cygwin.dll, and then run post-remove scripts. -- Eric In fact, there's no need to special-case cygwin1.dll -- just running the pre-remove scripts in a batch before all the package files are removed will work for 99% of the cases. Feel free to submit a patch on that one... Doing it right in general is very tricky, though. Suppose a pre-remove script for package B needs to run Atool from package A. But package A's pre-remove script removes the files needed for Atool to work. So, if the pre-remove script for A is run first, by the time B's pre-remove script is run, Atool no longer works, and thus B's
Re: perl Win32 lib support
On Tue, Feb 08, 2005 at 12:04:51PM -0800, linda w wrote: There must be something else involved or I've messed something else up: perl -v This is perl, v5.8.6 built for cygwin-thread-multi-64int ... I seem to have 5.8.6 installed. Is there anything else I should look at. I probably have something else messed up somewhere. :-/ Sigh. -linda Yitzchak Scott-Thoennes wrote: Upgrade to perl5.8.6, which addresses the IsWinNT-missing problem. Also, I believe Reini will be releasing a new version of perl-libwin32 real soon now. What exactly is giving the error, and what error are you getting? -- 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: Changing root path from /ecos-c/ to /
Hi Larry, Well, I wish it were that simple. That command doesnt work - it needs the Win32 file system to basic utilities like ls, etc. When eCos is installed, it somehow makes c: mount on /ecos-c, it previously was /. We're trying to find a way to put it back. Shane. Larry Hall wrote: At 12:20 AM 2/7/2005, you wrote: Hi, I'm using Cygwin. I wish to change the default path for C: from /ecos-c/ to /. When I type mount in cygwin, I get the following: C:\PFARM\cygwin on / type system (binmode) c: on /ecos-c type user (textmode) c: on / type user (textmode) e: on /cygdrive/e type user (textmode,noumount) f: on /cygdrive/f type user (textmode,noumount) h: on /cygdrive/h type user (textmode,noumount) i: on /cygdrive/i type user (textmode,noumount) C:\PFARM\examples\EVBA7Board\GNU\Simple\RAMCode The utility I'm using fails unless C: on the Windows box is mounted as '/'. Any suggestions? Shane. p.s. Whenever Cygwin generates a POSIX path from a Win32 one, it uses the longest matching prefix in the mount table. Thus, if C: is mounted as /c and also as /, then Cygwin would translate C:/foo/bar to /c/foo/bar. (http://www.cygwin.com/cygwin-ug-net/using.html#mount-table) Seems like you're answering your own question. Try 'umount -f /ecos-c'. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Setting the Windows Path variable for children of a bash script....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, I could have *sworn* I tried that before and it didn't work, but
I tried it again, and it seems to be exactly what I wanted/hoped for.
Ugh...sorry for the unnecessary traffic and thanks for the quick
response!
-- Matt
On Feb 8, 2005, at 15:07, Igor Pechtchanski wrote:
On Tue, 8 Feb 2005, Matthew Bogosian wrote:
...
I'm trying to execute a cygwin-ignorant Windows binary from a bash
script.
However, the DLLs required to load this binary are not in the system-
or
user-wide Windows Path variable (nor do I want them to be). I'm
trying to
modify the environment before execution of this binary, but it
doesn't seem to
work. Here's what I've got:
# ...
Path=$(cygpath -pw ${PATH});$(cygpath -pw ${LD_LIBRARY_PATH})
export Path
exec /cygdrive/c/path/to/windows/binary.exe
LD_LIBRARY_PATH contains the paths in which the DLLs specific to
binary.exe
reside. Unfortunately, binary.exe doesn't seem to be able to find
them there
when being invoked from the script's exec command.
...
PATH=${PATH}:${LD_LIBRARY_PATH}
export PATH
exec /cygdrive/c/path/to/windows/binary.exe
The PATH variable is treated specially by Cygwin and is translated
from
POSIX path format to Windows path format when calling Windows programs.
In your first case it was doing the translation twice, so C:\WINDOWS
became C;C:\WINDOWS.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCCVc7nLpDzL5I7l8RAifPAJ9XGh1lXCI/4rnWZ5WV21hojnYeKwCeJbGc
UFID820EZT1+ZKk5SRGrzbo=
=N/u5
-END PGP SIGNATURE-
--
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: bash: tab completion failure from (but not at) /
Corinna Vinschen wrote: On Feb 8 07:19, [EMAIL PROTECTED] wrote: Recent remarks (I have an idea about how to fix the race but it would introduce a destabilizing change that I'd rather not chance before 1.5.13 is released) suggest that an updated cygwin1.dll might be imminent. Please could I mention a minor but annoying glitch described along with Corinna's immediate and effective fix at http://www.cygwin.com/ml/cygwin/2004-05/msg00449.html but which has re-emerged in recent snapshots, at least since http://www.cygwin.com/ml/cygwin/2004-12/msg00838.html, in which Corinna records her perplexity (weird) at this re-emergence. Things worked properly in snapshot 20041222 but fail from 20041223. Nevertheless, that's a bash problem. Is our bash maintainer still around? Yep, still here.. I'll have a look at what your patch in Bash is up to tomorrow (still don't have a Windows machine at home) but it should be compiled in - there's no reason why it wouldn't be: the only thing I haven't changed is a fix for http://cygwin.com/ml/cygwin/2004-09/msg01517.html. I'll report back when I've checked (ping me if that doesn't happen in 24 hours - I'm rather busy lately...) rlc -- 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/
Help with deleting Cygwin shortcuts
Hello! Can someone help me with deleting all the files from the \Cygwin directory? I was able to delete about 99% of the files in the directories, but some files stated that they cannot be deleted because Access is Denied. Make sure the disk is not full or write protected. I tried everything from 'Safe Mode' to deleting with Cmd. All of these files are Shortcuts to some other files. Ex. d:\cygwin\etc\hosts cannot be deleted. I even tried cutting them into the recycle bin. I am also sure that the shortcuts are not used by any programs or services. Any help would be appreciated!!! -Ivan Lenev -- 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: Help with deleting Cygwin shortcuts
On Feb 8, 2005, at 5:23 PM, Ivan Lenev wrote: Hello! Can someone help me with deleting all the files from the \Cygwin directory? I was able to delete about 99% of the files in the directories, but some files stated that they cannot be deleted because Access is Denied. Make sure the disk is not full or write protected. I tried everything from 'Safe Mode' to deleting with Cmd. All of these files are Shortcuts to some other files. Ex. d:\cygwin\etc\hosts cannot be deleted. I even tried cutting them into the recycle bin. I am also sure that the shortcuts are not used by any programs or services. Any help would be appreciated!!! -Ivan Lenev Have you tried change or looking at the permissions on the shortcuts? Enjoy, Peter --- A Møøse once bit my sister -- 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: Re: Help with deleting Cygwin shortcuts
I'm pretty sure that I have full access since I'm the only user, and I don't see a Security/Permissions Tab in the properties of any of my files. I'm running WinXP Home, and no file sharing. -Ivan Lenev On Tue Feb 8 18:51 , Peter Rehley [EMAIL PROTECTED] sent: On Feb 8, 2005, at 5:23 PM, Ivan Lenev wrote: Hello! Can someone help me with deleting all the files from the \Cygwin directory? I was able to delete about 99% of the files in the directories, but some files stated that they cannot be deleted because Access is Denied. Make sure the disk is not full or write protected. I tried everything from 'Safe Mode' to deleting with Cmd. All of these files are Shortcuts to some other files. Ex. d:\cygwin\etc\hosts cannot be deleted. I even tried cutting them into the recycle bin. I am also sure that the shortcuts are not used by any programs or services. Any help would be appreciated!!! -Ivan Lenev Have you tried change or looking at the permissions on the shortcuts? Enjoy, Peter --- A Møøse once bit my sister -- 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/ -Ivan Lenev -- 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/
strange cp behavior with (coreutils 5.2.1)
$ net use shiva /u:shiva\\administrator $ cp //shiva/c\$/cvsmq/eqgame.h . cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for reading: No such file or directory $ net use shiva /d $ net use shiva /u:develop\\dkaa $ cp -v //shiva/c\$/cvsmq/eqgame.h . `//shiva/c$/cvsmq/eqgame.h' - `./eqgame.h' I think this used to work when cp was part of fileutils. The file itself has owner (develop\dkaa) read permissions but Everyone has no explicit permissions. Giving Everyone read permissions makes it work. This file was generated with cvs. On the server: $ ls -l eqgame.h -rw-rw-r--1 dkaa group31497 Jan 31 18:25 eqgame.h Is this a real bug? Thanks. __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.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: Changing root path from /ecos-c/ to /
At 07:13 PM 2/8/2005, you wrote: Hi Larry, Well, I wish it were that simple. That command doesnt work - it needs the Win32 file system to basic utilities like ls, etc. Huh? 'umount' is a command that doesn't rely on any other command. It's a separate executable. See 'man umount' for more details. When eCos is installed, it somehow makes c: mount on /ecos-c, it previously was /. We're trying to find a way to put it back. True enough. And technically since this is an issue with eCos, you will really need to follow-up with them if 'umount' won't work for you for some reason and the docs I pointed you to don't help you either. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: strange cp behavior with (coreutils 5.2.1)
At 10:15 PM 2/8/2005, you wrote: $ net use shiva /u:shiva\\administrator $ cp //shiva/c\$/cvsmq/eqgame.h . cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for reading: No such file or directory $ net use shiva /d $ net use shiva /u:develop\\dkaa $ cp -v //shiva/c\$/cvsmq/eqgame.h . `//shiva/c$/cvsmq/eqgame.h' - `./eqgame.h' I think this used to work when cp was part of fileutils. The file itself has owner (develop\dkaa) read permissions but Everyone has no explicit permissions. Giving Everyone read permissions makes it work. That doesn't sound strange to me at all. If you don't have any access to the file as the user of the share, I wouldn't expect to be able to access the file. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: strange cp behavior with (coreutils 5.2.1)
--- Larry Hall [EMAIL PROTECTED] wrote: At 10:15 PM 2/8/2005, you wrote: $ net use shiva /u:shiva\\administrator $ cp //shiva/c\$/cvsmq/eqgame.h . cp: cannot open `//shiva/c$/cvsmq/eqgame.h.exe' for reading: No such file or directory $ net use shiva /d $ net use shiva /u:develop\\dkaa $ cp -v //shiva/c\$/cvsmq/eqgame.h . `//shiva/c$/cvsmq/eqgame.h' - `./eqgame.h' I think this used to work when cp was part of fileutils. The file itself has owner (develop\dkaa) read permissions but Everyone has no explicit permissions. Giving Everyone read permissions makes it work. That doesn't sound strange to me at all. If you don't have any access to the file as the user of the share, I wouldn't expect to be able to access the file. I don't really have a problem with the lack of access, it's the fact that cp complains about the file with .exe suffix. Everyone has readexecute privileges for the directory of the file so cp should know the file is there and unreadable. Thanks. __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.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: RXVT copy/paste behavior
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn Sent: Tuesday, February 08, 2005 1:25 PM To: cygwin@cygwin.com Subject: RE: RXVT copy/paste behavior -Original Message- From: cygwin-owner On Behalf Of Phil Betts Sent: 08 February 2005 17:09 The selection model used by rxvt is standard throughout the X11 world. It's insane. I'm with you 1000% on this one Korny, and for every reason you've stated. The short answer to it though is this: contrary to most Unix-heads' beliefs, the world did not stop on the date that Unix was invented. Progress (dare I say, innovation?) has in fact occurred since the first line of C code was written, the last VT-100 terminal was thrown in the trash, and the X-Windows mess was thought up. -- Gary R. Van Sickle -- 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: Changing root path from /ecos-c/ to /
Hi Larry, Tried it again, and it worked this time. Had to restart the shell. Thanks for your help. Shane. Larry Hall wrote: At 07:13 PM 2/8/2005, you wrote: Hi Larry, Well, I wish it were that simple. That command doesnt work - it needs the Win32 file system to basic utilities like ls, etc. Huh? 'umount' is a command that doesn't rely on any other command. It's a separate executable. See 'man umount' for more details. When eCos is installed, it somehow makes c: mount on /ecos-c, it previously was /. We're trying to find a way to put it back. True enough. And technically since this is an issue with eCos, you will really need to follow-up with them if 'umount' won't work for you for some reason and the docs I pointed you to don't help you either. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Regards, Shane Tolmie (BEng. Elec. Hons.) Managing Director DesignREM Ltd. Cell: +64(21)2977741 Phone: +64(3)3793012 Fax: +64(3)3660118 [EMAIL PROTECTED] www.designrem.com This email or attachments may contain confidential or legally privileged information intended for the sole use of the addressee(s). Any use, redistribution, disclosure, or reproduction of this message, except as intended, is prohibited. If you received this email in error, please notify the sender and remove all copies of the message, including any attachments. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sshd ssh_exchange_identification: Connection closed by remote host until restarted
Cygwin: I recently rebuilt my XP Pro SP2 workstation and re-installed Cygwin. I noticed that when the machine is booted, sshd is unresponsive until I manually stop and restart it: [EMAIL PROTECTED]:~$ date Tue Feb 8 21:02:53 PST 2005 [EMAIL PROTECTED]:~$ ssh localhost ssh_exchange_identification: Connection closed by remote host [EMAIL PROTECTED]:~$ cygcheck -s -v -r cygcheck.out [EMAIL PROTECTED]:~$ date Tue Feb 8 21:04:01 PST 2005 [EMAIL PROTECTED]:~$ ssh localhost ssh_exchange_identification: Connection closed by remote host [EMAIL PROTECTED]:~$ date Tue Feb 8 21:11:45 PST 2005 [EMAIL PROTECTED]:~$ ssh localhost ssh_exchange_identification: Connection closed by remote host [EMAIL PROTECTED]:~$ net stop sshd The CYGWIN sshd service is stopping. The CYGWIN sshd service was stopped successfully. [EMAIL PROTECTED]:~$ net start sshd The CYGWIN sshd service is starting. The CYGWIN sshd service was started successfully. [EMAIL PROTECTED]:~$ ssh localhost Last login: Tue Feb 8 21:00:49 2005 from localhost [EMAIL PROTECTED]:~$ exit logout Connection to localhost closed. [EMAIL PROTECTED]:~$ Any suggestions? TIA, David cygcheck.out Description: Binary data -- 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: Help with deleting Cygwin shortcuts
Ivan Lenev wrote: I'm pretty sure that I have full access since I'm the only user, and I don't see a Security/Permissions Tab in the properties of any of my files. I'm running WinXP Home, and no file sharing. XP Home sucks, get a book about XP where is described how to tweak security settings anyway. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
New user on Cygwin
Good morning, I'm Stefano Bigoni, System Admin of University of Ferrara (Italy). I installed yesterday CygWin on a Windows XP Professional Platform. I've been searching on help the procedure to set-up a sftp external new user, but I can't find any information about it. Could you help me, please? Thanks in advance Dott. Stefano Bigoni -- 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: cygwin1.dll crash
hi again the problem is solved (blushing...) I rebooted my computer, and now everything works fine again thanks for your time;-/ On Tue, 8 Feb 2005 17:06:34 +0100, Lannoye Xavier [EMAIL PROTECTED] wrote: I've tried what you said, cleaned my PATH var (using control panel, ...) but it doesn't work. still the same problem I ran a new IExporer window, to make sure it takes the new path values. I could do a full uninstall of cygwin, and install a clean one, but that looks so terrible;-( thks On Tue, 8 Feb 2005 15:48:41 -, Dave Korn [EMAIL PROTECTED] wrote: -Original Message- From: cygwin-owner On Behalf Of Lannoye Xavier Sent: 08 February 2005 14:50 here you have the output for dir /w its quite huge Directory of C:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86 [.] [..] a2p.exe perl.dll perl.exe perl5.00503.exe perl95.exeperlglob.exe 6 File(s)987.136 bytes This is ActiveState perl, so I was wrong in my first guess. I'm still suspicious that it's the root cause of the trouble though; if any of the setup.exe post-install scripts rely on perl, they are liable to invoke active state perl instead of cygwin perl, and break when it fails to understand cygwin-style POSIX paths. I've put the cygwin path in top of my PATH var. but still the same problem Hmm, peculiar. May need some more thinking time over this. Precisely how did you set it? If you do it using the PATH command in a DOS prompt, that wouldn't affect a copy of setup.exe that you launched from explorer, you do need to set it in Start Menu / Settings / Control Panel / System / Advanced / Environment Variables. Try setting your PATH to nothing but these entries: C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem and see if that helps any. 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/ -- 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 digest format
Could the digest format be changed into a single message format containing all the messages instead of a single message with other messages embeddded as attachments? I don't know what others think but IMO its easier to read browse through a single message than opening individual attachment, unless (of course) there are strong reasons for the current digest format. Gorden Jemwa -- 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/
