Cygwin 1.5.6-1 completely breaks bash
I updated to Cygwin.dll 1.5.6-1 yesterday, and today bash won't start. It hangs somewhere in the startup scripts. The scripts are unchanged for several months, and they worked just fine yesterday. I've tried to pin down the place in the startup scripts where bash hangs, but it jumps around. In one case a grep command in /etc/profile.d/00xfree.sh (which worked fine yesterday) hangs. I comment it out, and get as far as somewhere in the middle of my ~/.bash_profile; but then the next time I start, another script in /etc/profile.d hangs. For now I've regressed to Cygwin 1.5.5-1, and the problem has gone away. -- 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: Cygwin 1.5.6-1 completely breaks bash
> I updated to Cygwin.dll 1.5.6-1 yesterday, and today bash won't start. > It hangs somewhere in the startup scripts. The scripts are unchanged > for several months, and they worked just fine yesterday. Here is output from cygcheck under 1.5.6-1 (run from cmd, since bash won't start): C:\Documents and Settings\aschulma>cygcheck -src Cygwin Package Information Package VersionStatus _update-info-dir00226-1OK ash 20031007-1 OK base-files 2.6-1 OK base-passwd 1.1-1 OK bash2.05b-16 OK binutils20030901-1 OK bison 20030307-1 OK bzip2 1.0.2-5OK clear 1.0-1 OK crypt 1.1-1 OK cygipc 2.02-1 OK cygrunsrv 0.97-1 OK cygutils1.2.2-1OK cygwin 1.5.6-1OK cygwin-doc 1.3-6 OK diffutils 2.8.4-1OK editrights 1.01-1 OK expat 1.95.7-1 OK expect 20030128-1 OK file4.06-1 OK fileutils 4.1-2 OK findutils 4.1.7-4OK flex2.5.4a-3 OK fontconfig 2.2.0-1OK freetype2 2.1.5-1OK fvwm2.4.7-3OK gawk3.1.3-4OK gcc 3.3.1-3OK gcc-mingw-core 20031020-1 OK gdbm1.8.3-7OK gettext 0.12.1-3 OK ghostscript 7.05-2 OK ghostscript-base7.05-2 OK ghostscript-x11 7.05-2 OK gnupg 1.2.2-3OK grep2.5-1 OK groff 1.18.1-2 OK gzip1.3.5-1OK ImageMagick 5.5.7-2OK indent 2.2.9-1OK inetutils 1.3.2-25 OK jbigkit 1.5-3 OK jpeg6b-11 OK keychain2.0.3-2OK less381-1 OK lftp2.6.10-1 OK libbz2_11.0.2-5OK libdb3.13.1.17-2 OK libdb4.14.1.25-1 OK libfontconfig1 2.2.0-1OK libfreetype26 2.1.5-1OK libgdbm 1.8.0-5OK libgdbm-devel 1.8.3-7OK libgdbm31.8.3-3OK libgdbm41.8.3-7OK libgettextpo0 0.12.1-3 OK libiconv2 1.9.1-3OK libintl 0.10.38-3 OK libintl10.10.40-1 OK libintl20.12.1-3 OK libjpeg62 6b-11 OK libjpeg6b 6b-8 OK libMagick6 5.5.7-2OK libncurses5 5.2-1 OK libncurses6 5.2-8 OK libncurses7 5.3-4 OK libpcre 4.1-1 OK libpcre04.5-1 OK libpng 1.2.5-4OK libpng101.0.15-4 OK libpng121.2.5-4OK libpopt01.6.4-4OK libPropList 0.10.1-3 OK libreadline44.1-2 OK libreadline54.3-5 OK libtiff-devel 3.6.0-5OK libtiff33.6.0-2OK libtiff43.6.0-5OK libxml2 2.6.4-1OK login 1.9-7 OK lynx2.8.4-7OK m4 1.4-1 OK make3.80-1 OK man 1.5k-2 OK mingw-runtime 3.2-1 OK mktemp 1.5-3 OK nano1.2.2-1OK ncftp 3.1.4-1OK ncurses 5.3-4 OK netcat 1.10-2 OK newlib-man 20020801 OK openssh 3.7.1p2-2 OK openssl 0.9.7c-1 OK openssl-devel 0.9.7c-1 OK openssl096 0.9.6j-1 OK par 1.52-1 OK patch 2.5.8-8OK patchutils 0.2.22-2 OK pcre4.5-1 OK pcre-doc4.
Re: Cygwin 1.5.6-1 completely breaks bash
> You might want to read the list this is a know issue. > Try the latest snapshot 1.5.7 Okay, sorry. I do read the list but missed that. -- 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[4]: 'bash --login -i' takes 9 secs !
> IP> (...) this is not a Cygwin problem at all. (...) > > Thank you Igor, > you were very helpful, indeed. > Of course, this was not a cygwin problem, > and narrowing it down to the cygwin_gethostname call > directed me to some old thread: > http://www.cygwin.com/ml/cygwin/2003-03/msg00097.html > (I was not alone :-) > > Novell client problem, solved by applying novell client patch. > Thanks again, > Pawel Hallelujah. I had this problem for a long time, and it just went away on its own-- and my admins recently patched my Novell client. -- 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: Cygwin under Wine?
> Can Cygwin currently run under Wine? A buggy, incomplete emulator running inside a buggy, incomplete emulator? It sounds hellish. -- 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: Cygwin setup window size, why no maximize button enabled ?
> http://cygwin.com/setup-snapshots/ Hallelujah, a resizable setup program. What a relief. Now if only it would recognize my mouse wheel... -- 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: Cygwin setup window size, why no maximize button enabled ?
> > > http://cygwin.com/setup-snapshots/ > > > > Hallelujah, a resizable setup program. What a relief. > > > > Now if only it would recognize my mouse wheel... > > It depends on windows to send the appropriate messages. What OS and what > mouse are you using? Win2K SP4, with a Logitech generic mouse. Other apps recognize my mouse wheel, so I don't think it's a Windows message problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to get IP with a shell command?
ipconfig | grep 'IP Address' | sed -e 's/.* //' -- 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/
autossh
Has anyone had any success in building autossh for cygwin? I have version 1.2f. When I try to compile it with any of the provided Makefiles, I get a boatload of errors: $ make -f Makefile.linux gcc -Wall -D"SSH_PATH=\"/usr/bin/ssh\"" -D"VER=\"1.2f\"" -c -o autossh.o autos sh.c autossh.c:126: warning: `struct addrinfo' declared inside parameter list autossh.c:126: warning: its scope is only this definition or declaration, which is probably not what you want autossh.c:951: warning: `struct addrinfo' declared inside parameter list autossh.c:952: error: conflicting types for `conn_addr' autossh.c:126: error: previous declaration of `conn_addr' autossh.c: In function `conn_addr': autossh.c:954: error: storage size of `hints' isn't known autossh.c:957: error: invalid application of `sizeof' to an incomplete type autossh.c:963: error: `AI_PASSIVE' undeclared (first use in this function) autossh.c:963: error: (Each undeclared identifier is reported only once autossh.c:963: error: for each function it appears in.) autossh.c:972: warning: implicit declaration of function `getaddrinfo' autossh.c:973: warning: implicit declaration of function `gai_strerror' autossh.c:954: warning: unused variable `hints' autossh.c: In function `conn_remote': autossh.c:989: warning: passing arg 3 of `conn_addr' from incompatible pointer t ype autossh.c:991: error: dereferencing pointer to incomplete type autossh.c:991: error: dereferencing pointer to incomplete type autossh.c:992: error: dereferencing pointer to incomplete type autossh.c:995: error: dereferencing pointer to incomplete type autossh.c:995: error: dereferencing pointer to incomplete type autossh.c: In function `conn_listen': autossh.c:1020: warning: passing arg 3 of `conn_addr' from incompatible pointer type autossh.c:1022: error: dereferencing pointer to incomplete type autossh.c:1022: error: dereferencing pointer to incomplete type autossh.c:1023: error: dereferencing pointer to incomplete type autossh.c:1031: error: dereferencing pointer to incomplete type autossh.c:1032: error: dereferencing pointer to incomplete type autossh.c:1039: warning: implicit declaration of function `freeaddrinfo' make: *** [autossh.o] Error 1 Thanks, Andrew. -- 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: unison-gtk2-2.10.2-1
> > I'm sorry but I never have packaged unison-gtk2 for Cygwin. I did try > > at first, but ran into a fatal error that seemed to be caused by > > lablgtk2, the OCaml interface to GTK2. I wasn't able to solve it right > > away, and since I only use the text interface myself, I've never gotten > > back to it. > > lablgtk2 doesn't build OOTB on Cygwin, as it assumes that we use a Win32 > target instead of X11. > > I'm attaching a patch which I used to compile lablgtk2, or if you > prefer, I have packages available at: > > ftp://sunsite.dk/projects/cygwinports/release/ocaml/lablgtk2/ > > As I know nothing about OCaml, I don't know if this will fix the patch, > but perhaps it could be a start to getting this working. Yaakov, sorry I didn't get back to you sooner. As part of my attempt to build unison-gtk2 for Cygwin, I did successfully build and package lablgtk2 for Cygwin. It's available through the setup utility. So the problem isn't building lablgtk2, but rather an error in unison-gtk2 that seems to be caused by lablgtk2. But it's been a while and I'm afraid I don't remember the details now. -- 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/
bindresvport(): can it be exported from cygwin1.dll?
I'm trying to build dante, a SOCKS client and server, for Cygwin. Right now build is failing with .libs/Rbindresvport.o: In function `Rbindresvport': /usr/local/src/dante-1.1.19/lib/Rbindresvport.c:68: undefined reference to `_bindresvport' based on a call to bindresvport(). bindresvport() is normally declared in netinet/in.h, but in Cygwin it's missing. I see that bindresvport.c is part of the cygwin source code. Would it be possible to have it exported from cygwin1.dll? Thanks, Andrew. -- 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: bindresvport(): can it be exported from cygwin1.dll?
> > I see that bindresvport.c is part of the cygwin source code. > > You have apparently better eyes then I have. Where did you see that > bindresvport function in Cygwin? > > If you're talking about the implementation in newlib/libc/sys/linux/... > then it's unusable for Cygwin. There's a reason it's in the linux > subdirectory... Ah... ok. > > Would it be > > possible to have it exported from cygwin1.dll? > > No. We need a implementation which uses the limited functionality > of WinSock. It's not that hard, but it's definitely not going to be > in 1.5.20. http://cygwin.com/acronyms/#SHTDI OK, I'll have a look at it. Any ready pointers would be welcome. A. -- 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, find | xargs grep
> I've been doing "find | xargs grep" types of things Bob, I don't know the source of your trouble, but as a workaround consider running grep -r instead of find | xargs grep. In many cases it's equivalent or almost as good, and it probably will avoid all of the forking that's causing trouble for you. A. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: LFTP Version 2.6.10 is very old
> The current version of LFTP available in Cygwin seems to be V2.6.10, which > is very old now (December 2003!). The current version is 3.4.4, from April > 2006. Any chance of this being updated, or me being pointed in the right > direction to do it myself? I also use and like lftp, so if the current maintainer has gone AWOL, I'd be willing to take over the package and issue an update. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: LFTP Version 2.6.10 is very old
> > Last I heard, lftp was "up-for-grabs". You could check the archives of the > > cygwin-apps list to see if I missed an update. Corinna has been the one > > managing this list. But she won't be able to correct me if I'm wrong for > > a few weeks. So I'd say, if you're interested, go for it. > > Yes, lftp was in the list of orphaned packages per Corinna's last list, > so consider it up for grabs. OK. Version 3.4.4 builds OOTB, so I'll package and ITP it within the next few days. A. -- 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: autossh broken with current openssh/cygwin
> > $ AUTOSSH_FIRST_POLL=5 AUTOSSH_POLL=5 AUTOSSH_DEBUG=yes autossh -M 3 > > -N dessent.net > > autossh: PID 3204: short poll time: adjusting net timeouts to 2500 > > autossh: PID 3204: checking for grace period, tries = 0 > > autossh: PID 3204: starting ssh (count 1) > > autossh: PID 3204: ssh child pid is 4160 > > autossh: PID 4160: execing /usr/bin/ssh > > autossh: PID 3204: check on child 4160 > > autossh: PID 3204: set alarm for 5 secs > > autossh: PID 3204: timeout on io poll, looping to accept again > > Confirmed. This has been introduced by trying to get the WinSock event > driven accept thread-safe. This apparently doesn't work as expected. > To get that really right, a lot more has to be done. Since that's > nothing I'd like to rip apart before 1.5.20, I reverted all event > handling for accept and connect and returned to using select again, as > it was implemented until 1.5.18. Whew! Saved my ass on that one... -- 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: cygwin-developers mailing list opened up a little
> > May I ask at gmane.org to add the cygwin-developers list there ? > > I'd rather avoid that. I can't speak for cgf, but I'm somewhat > confident that he thinks the same. Opening the list didn't imply that > we're interested in zillions of lurkers. People interested in helping > to develop the Cygwin DLL itself are invited to join the list. A subtle distinction. I fully intend to lurk for quite a while as a way to start learning about the internals. Eventually a problem may come up that I think I'm ready to take a crack at. -- 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: Cygwin and screen
Ed Peschko wrote: > I was wondering if you ever got around to fixing that screen detaching > bug (ie: the parent being unable to be closed due to an active screen > process being around. I really like screen, and would like to use it as > it was intended on cygwin.. Hi Ed. No, I never was able to fix it. Not for lack of trying, but terminal stuff is deeply confusing to me. I never got very far with it. FWIW, you can download my last builds from http://home.comcast.net/~andrex/cygwin/screen/screen-4.0.2-0test1.tar.bz2 http://home.comcast.net/~andrex/cygwin/screen/screen-4.0.2-0test1-src.tar.bz2 You can untar the binary package with e.g. tar -jx -C / -f screen-4.0.2-0test1.tar.bz2 and it will mostly work. You get a multiplexed screen. But when you detach a session most of the time you can't reattach to it, even though the processes live on so you have to kill them by hand. There were some other minor problems that I forget right now. screen is an extremely useful program, and I wish someone could solve the Cygwin problems with it. Many people have tried over the years. I'd be happy to package it for Cygwin if someone could get it working. Good luck, Andrew. -- 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: Cygwin ans screen
> > screen is an extremely useful program, and I wish someone could solve > > the Cygwin problems with it. Many people have tried over the years. > > I'd be happy to package it for Cygwin if someone could get it working. > > I would think that packaging it a with few minor bugs is better than > waiting, ie. more likely to spur/inspire someone with the skills to > look more deeply. The last time I floated that idea on cygwin-apps, the Cygwin project admins disagreed. But maybe it's worth a try again. -- 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: Cygwin ans screen
> On 7/19/06, Duane Krings wrote: > > Andrew Schulman wrote: > > > and it will mostly work. You get a multiplexed screen. But when you > > > detach a session most of the time you can't reattach to it, even > > > though the processes live on so you have to kill them by hand. There > > > were some other minor problems that I forget right now. > > > > The behavior I see is: > > 1) start screen in xterm #1 then detach > > 2) try to reattach in xterm #1 fails > > 3) reattach with xterm #2 works > > 4) try to reattach in xterm #1 still fails > > or in general, the first terminal that tries to reattach to a running > > screen session is forever locked out, but all subsequent terminals > > will succeed. > > Give Mark Edgar's patch[*] a try. With it applied, screen behaves > better under Cygwin for me. Reattaching from the same terminal and > multi-display mode both work. There are still some problems, however. > Detaches sometimes get hung. Opening a new terminal and running > 'screen -list' will cause the hung detach to complete most of the > time. > > [*] Mark Edgar's patch > http://gecko.gc.maricopa.edu/~medgar/screen.html OK, I'll look at this as soon as I can. From what people have reported here, it sounds as though it makes screen work well enough to at least package as a test version. -- 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: Revised: ls: reading directory .: No such file or directory
> [EMAIL PROTECTED] ~ > $ cd c: > > [EMAIL PROTECTED] /cygdrive/c > $ ls > ls: reading directory .: No such file or directory WAG: if you run 'cd /cygdrive/c' instead of 'cd c:', does the problem go away? The shell obviously is interpreting c: as /cygdrive/c in your shell prompt, but maybe it's storing c: instead of /cygdrive/c as the current directory, and choking on that. -- 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: Revised: ls: reading directory .: No such file or directory
> On Tue, Aug 01, 2006 at 09:15:44AM -0600, Monte Riding wrote: > >I have an issue when trying to run ls in the root of my C: drive > >that's cropped up recently, not sure what's happened - > > Morale of the story: Use POSIX paths, i.e. "cd /cygdrive/c". OK, but mightn't it be considered a bug that Cygwin is being inconsistent in its treatment of non-POSIX paths? The CWD is stored as C:. bash then presents it (and apparently sees it) as /cygdrive/c. ls OTOH apparently sees it as C:, which it can't properly interpret. I'm not sure who's at fault (Cygwin DLL, bash, or ls), but something is getting garbled in translation. [slips armored helmet on] -- 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: Revised: ls: reading directory .: No such file or directory
> [EMAIL PROTECTED] ~ > $ cd /cygdrive/c > > [EMAIL PROTECTED] /cygdrive/c > $ ls > ls: reading directory .: No such file or directory Permission problem on the root folder of C:? -- 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: unison doesn't honor HOME when USERPROFILE is set, also permission/uid/gid problems when synchronizing
Hi Volker. > I installed unison-2.10.2-1 and tried to sync 2 directories > with the following default.prf in my /home/vzell/.unison > > # Unison preferences file > owner=true > group=true > perms=-1 > log=true > > First of all unison didn't find my $HOME/.unison but instead created a > new one under C:\Documents and Settings\vzell :-( ugh > and second unison > didn't honour the above preferences after editing the new > C:\Documents and Settings\vzell\.unison\default.prf. > > > I compiled already unison in 2002 and used it to sync files with > different owner/group membership and, in case of new files with > permissions different from the umask value, I wanted unison to also sync > permissions. Both of this can be achieved with the patch below. > > Any chance that this can be incorporated in the next release ? > > > --- util.ml.orig2004-09-28 09:45:32.940632000 +0200 > +++ util.ml 2004-09-28 08:40:28.926936000 +0200 > @@ -358,10 +358,10 @@ >match osType with > `Win32 -> >let dirString = > -try Unix.getenv "USERPROFILE" (* Windows NT/2K *) > -with Not_found -> > try Unix.getenv "HOME" (* Windows 9x with Cygwin HOME set *) > with Not_found -> > +try Unix.getenv "USERPROFILE" (* Windows NT/2K *) > +with Not_found -> > try Unix.getenv "UNISON" (* Use UNISON dir if none of > the above are set *) > with Not_found -> "c:/" (* Default *) in According to the Unison manual (http://www.cis.upenn.edu/ ~bcpierce/unison/download/beta-test/latest/unison- manual.html#unisondir), on Unix hosts Unison looks in order in $UNISON and $HOME/.unison; on Windows hosts it looks in order in $UNISON, $USERPROFILE\.unison, $HOME\.unison, and C:\.unison. So there are two issues here: (1) Unison is looking in $UNISON last. This is clearly wrong, and if fixed would allow you to solve your problem by setting UNISON=/home/volker/.unison. But here's something I don't understand: on my Cygwin host both UNISON and USERPROFILE are set, but UNISON takes precedence. ?? Are you sure this section of code is the operative one here? What happens if you export UNISON=/home/vzell/.unison? (2) It seems that Unison treats Cygwin as a Windows OS for this purpose, so that it looks in $USERPROFILE/.unison before $HOME/.unison. This is arguably wrong, but I think I'll have to pose the question on unison- hackers. > --- uicommon.ml.orig2004-09-28 09:43:28.010992000 +0200 > +++ uicommon.ml 2004-09-28 08:41:27.090571200 +0200 > @@ -346,7 +346,7 @@ >let someHostIsCaseInsensitive = > someHostIsRunningWindows || someHostRunningOsX in >Case.init someHostIsCaseInsensitive; > - Props.init someHostIsRunningWindows; > +(* Props.init someHostIsRunningWindows; *) >Osx.init someHostRunningOsX; >return ()) And this patch solves the owner and group sync problem? Sorry but it's not obvious to me. You say Unison "didn't honor" the owner and group preferences. What exactly happened? Did it just not sync the owners and groups, or did it give you error messages? > By the way I had to export also the following env var to compile from > source: > > export OSCOMP=cygwingnuc Yup. This is documented in /usr/share/doc/Cygwin/unison-2.10.2- 1.README. Gerrit Haase has been after me to provide a generic build script for building Unison from the source package, and when I make one it will include this. Thanks for your report. As soon as I'm sure that I have the right corrections, I'll release a new version that includes the fixes. Andrew. -- 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: unison doesn't honor HOME when USERPROFILE is set, also permission/uid/gid problems when synchronizing
> > (1) Unison is looking in $UNISON last. This is clearly wrong, and if > > fixed would allow you to solve your problem by setting > > UNISON=/home/volker/.unison. But here's something I don't understand: > > on my Cygwin host both UNISON and USERPROFILE are set, but UNISON takes > > precedence. ?? Are you sure this section of code is the operative one > > here? What happens if you export UNISON=/home/vzell/.unison? > > In that case it will use $UNISON. > According to the file strings.ml: > > \032 Unison stores a variety of information in a private directory on each\n\ > \032 host. If the environment variable UNISON is defined, then its value\n\ > \032 will be used as the name of this directory. If UNISON is not defined,\n\ > \032 then the name of the directory depends on which operating system you\n\ > \032 are using. In Unix, the default is to use $HOME/.unison. In Windows,\n\ > \032 if the environment variable USERPROFILE is defined, then the directory\n\ > \032 will be $USERPROFILE\\.unison; otherwise if HOME is defined, it will > be\n\ > \032 $HOME\\.unison; otherwise, it will be c:\\.unison.\n\ > \032 \n\ Okay, but that's not what the code snippet you cited appears to show: match osType with `Win32 -> let dirString = try Unix.getenv "USERPROFILE" (* Windows NT/2K *) with Not_found -> try Unix.getenv "HOME" (* Windows 9x with Cygwin HOME set *) with Not_found -> try Unix.getenv "UNISON" (* Use UNISON dir if none of the above are set *) with Not_found -> "c:/" (* Default *) in I don't know OCaml, but that sure looks to me as though $UNISON is only used if $USERPROFILE and $HOME are not set. And yet that behavior doesn't match what I observe on my host. So that's why I asked, what happens if you export UNISON=/home/volker/.unison and rerun? Does unison use $UNISON, or $USERPROFILE/.unison? -- 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: unison doesn't honor HOME when USERPROFILE is set, also permission/uid/gid problems when synchronizing
> > I don't know OCaml, but that sure looks to me as though $UNISON is only > > used if $USERPROFILE and $HOME are not set. And yet that behavior > > doesn't match what I observe on my host. So that's why I asked, what > > happens if you export UNISON=/home/volker/.unison and rerun? Does > > unison use $UNISON, or $USERPROFILE/.unison? > > As I told you above. It uses $UNISON also in my case. OK. > Probably this part from os.ml takes precedence then: > > (*) > (* UNISON DIRECTORY*) > (*) > > (* Gives the fspath of the archive directory on the machine, depending on*) > (* which OS we use *) > let unisonDir = > try Fspath.canonize (Some (Unix.getenv "UNISON")) > with Not_found -> > let genericName = Util.fileInHomeDir (Printf.sprintf ".%s" Uutil.myName) in > if Osx.isMacOSX then > let osxName = Util.fileInHomeDir "Library/Application Support/Unison" in > if Sys.file_exists genericName then Fspath.canonize (Some genericName) > else Fspath.canonize (Some osxName) > else > Fspath.canonize (Some genericName) Yes, that probably explains it. > So the first part of my patch seems ok: > > --- util.ml.orig2004-09-28 09:45:32.940632000 +0200 > +++ util.ml 2004-09-28 08:40:28.926936000 +0200 > @@ -358,10 +358,10 @@ > match osType with > `Win32 -> > let dirString = > -try Unix.getenv "USERPROFILE" (* Windows NT/2K *) > -with Not_found -> > try Unix.getenv "HOME" (* Windows 9x with Cygwin HOME set *) > with Not_found -> > +try Unix.getenv "USERPROFILE" (* Windows NT/2K *) > +with Not_found -> > try Unix.getenv "UNISON" (* Use UNISON dir if none of > the above are set *) > with Not_found -> "c:/" (* Default *) in No, I think it should be --- util.ml.orig2004-09-28 09:45:32.940632000 +0200 +++ util.ml 2004-09-28 08:40:28.926936000 +0200 @@ -358,10 +358,10 @@ match osType with `Win32 -> let dirString = +try Unix.getenv "UNISON" (* Look for UNISON dir first *) +with Not_found -> try Unix.getenv "USERPROFILE" (* Windows NT/2K *) with Not_found -> try Unix.getenv "HOME" (* Windows 9x with Cygwin HOME set *) -with Not_found -> -try Unix.getenv "UNISON" (* Use UNISON dir if none of -the above are set *) with Not_found -> "c:/" (* Default *) in which is what the manual says Unison is supposed to do on a Windows host. Now whether Cygwin should count as a Windows host is a different question, which is probably harder to change. But there might be a case for changing this behavior, at least, to be Unix-like instead of Windows-like, for Cygwin. Anyway, as soon as I can get to it I'll pass your report and patches on to the unison-hackers list. Once they approve a fix I'll release a new Cygwin version. Thanks for your report. Andrew. -- 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/
make-3.80-1: "virtual memory exhausted" bug
make-3.80-1 suffers from the "virtual memory exhausted" bug: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02871.html Following that discussion thread leads to a patch available at https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=1517 (although I had to reformat the patch: try http://home.comcast.net/~andrex/misc/make-3.80-eval-crash.patch). The bug is triggered by passing a long string to the "eval" function. I ran into this recently and couldn't run make until I built a version patched with the above patch. Andrew. -- 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: make-3.80-1: "virtual memory exhausted" bug
Sorry, the link to the bug should have been http://www.mail-archive.com/[EMAIL PROTECTED]/msg02871.html -- 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: nul
> Once when I felt particulary stupid, I've added redirection to 'nul' > instead of '/dev/null' to a program run from cygwin cron. Now I've got a > file called 'nul' on NTFS disk and can do nothing about it neither with > windows tools nor from cygwin shell. Not a big problem, but annoying. Any > ideas on how to get rid of it? If you can't remove it, then its ownership or permissions probably aren't set to allow that. Take ownership of it, give yourself all permissions, and then delete it. If that doesn't work, try booting into the 2K/XP repair console, where you should be able to delete it. -- 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: A request for package announcers
> Would it be possible to include a description of what the package > actually is, in the email announcement? Even if it's very short. > > Often you can't tell from the package name alone. Yes, this is reasonable. Someone else asked for the same thing in this NG within the last week. Maybe the cygwin-announce moderator should set and enforce this policy. -- To reply by email, replace "deadspam.com" by "alumni.utexas.net" -- 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: why is -L/usr/local/lib necessary?
> > why doesn't "gcc -lfoo" (ld) find /usr/local/lib/foo.dll? > > what do I do to avoid this? > > Edit /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs Geez, that thing should be in /etc. -- To reply by email, replace "deadspam.com" by "alumni.utexas.net" -- 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: unison and cygwin on windows xp SP2
> > Now I was wondering if there was any progress in the meantime or if > > there are plans to develop a fix in the near future. Otherwise I would > > have to find a solution for unison without the cygwin ssh client. > > Your mileage should be greater if you use the cygwin build of unison, > available through setup.exe. > > I've had much less problems after I switched. I'm glad to hear it :) Actually there are a few known bugs in the current cygwin release of Unison. I have a patched version, but because of some packaging issues I haven't released it yet. I'll do so as soon as I can. Andrew. -- To reply by email, replace "deadspam.com" by "alumni.utexas.net" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with overloading of the semantics of version number in cygwin/unison
Hi Richard. I'm the maintainer of Unison for Cygwin. > There is a problem with the way that cygwin is updating the version > numbers for cygwin/unison. Unison is used to synchronize filesystems; > it can cross different operating systems over IP. The protocol uses the > version number to decide whether two processes on different systems will > communicate. 2.9.1 is the official released version. There is a beta > version 2.10.2, but it is not widely deployed. Thus people (like me) > will want to use the 2.9.1 version of cygwin's unison. However, cygwin > is numbering its instance of this version 2.9.20-1. When you try to > communicate using cygwin's 2.9.20-1 with a standard 2.9.1 version of > unison running on another system, the communication fails after the > handshake when it discovers that the cygwin version is "2.9.2 [sic]". > Yes, I think that the handshake is truncating the protocol string. You're right that Unison versions 2.9.1 and 2.9.20 won't talk to each other. Nor will either of them talk to 2.10.2, IIRC. Some of this may be just sloppy version checking, I'm not sure. At least some of it is required, because the Unison archive format has changed once or twice. If you tried to synchronize files using versions of Unison with incompatible archive formats, then bad things would happen, or so I'm told. That's the reason that the Cygwin developers put in the version checking. > Anyway, my suggestion is that cygwin update the version of 2.9.1 that it > is distributing, to separate the overloaded concept of version number > into a cygwin version number (which could then be arbitrary) and leave > the protocol number at 2.9.1 Other people have raised this problem before. I've been aware of it, but haven't managed to tackle it yet. Your proposed solution is right. Wherever the archive formats are incompatible, there should be a separate package. For example, instead of installing the latest Unison (e.g. 2.10.2-3, which may be incompatible with their server's version), the user could install whatever version of unison2.9.1, unison2.9.20, or unison2.10.2. The only reason this hasn't happened yet is because I haven't made it happen. I need to first find out for sure which versions have incompatible archive formats, or maybe just which versions will refuse to talk to each other. Then I'll have to redo all of my packaging work, say, 3 times over. Not impossible, but not enticing either. However, since only version 2.9.1 is available to you, I'll move it up in my queue and get to it ASAP. BTW, there have been a lot of new features and bug fixes since version 2.9.1. 2.10.2 is pretty stable; I think the developers are considering making a new stable release soon. If you can, consider asking your server admin to upgrade. Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with overloading of the semantics of version number in cygwin/unison
> Max Bowsher wrote: > > > Richard Lethin wrote: > > > >> Max Bowsher wrote: > >> > >>> Richard Lethin wrote: > >>> > There is a problem with the way that cygwin is updating the version > numbers for cygwin/unison. Unison is used to synchronize filesystems; > it can cross different operating systems over IP. The protocol uses > the > version number to decide whether two processes on different systems > will > communicate. 2.9.1 is the official released version. There is a beta > version 2.10.2, but it is not widely deployed. Thus people (like me) > will want to use the 2.9.1 version of cygwin's unison. However, cygwin > is numbering its instance of this version 2.9.20-1. When you try to > communicate using cygwin's 2.9.20-1 with a standard 2.9.1 version of > unison running on another system, the communication fails after the > handshake when it discovers that the cygwin version is "2.9.2 [sic]". > Yes, I think that the handshake is truncating the protocol string. > > Anyway, my suggestion is that cygwin update the version of 2.9.1 > that it > is distributing, to separate the overloaded concept of version number > into a cygwin version number (which could then be arbitrary) and leave > the protocol number at 2.9.1 > >>> > >>> > >>> > >>> No, this is nothing to do with cygwin, and everything to do with > >>> unnecessary inflexibility in the version checking of unison. > >>> > >>> It would be a very bad thing for Cygwin to distribute a version of > >>> unison which lies about which version it is to the other end of the > >>> connection. > >> > >> > >> Sure, it's a bad design choice in unison, but cygwin is using the > >> version number in Unison - which means something about the protocol > >> version in unison - to mean something about the software release - which > >> operationally is not what unison really means. The result is that > >> cygwin unison is broken. > > > > > > Unison itself uses the same version number for protocol of software > > release. > > That is a problem if you cannot obtain unison binaries for all machines > > you wish to synchronize between from a single source. > > Nothing in this problem is in any way cygwin specific. > > Where does the version number 2.9.20-1 come from? Internally, Unison's version number is 2.9.20. In the Cygwin distribution, that package is numbered 2.9.20-1 because it's the first release of Unison 2.9.20 in Cygwin. If I were to apply some bug fixes or other changes and release a new version of 2.9.20, it would show up in the Cygwin mirrors as 2.9.20-2. But Unison would still tell you that you were using version 2.9.20. HTH, A. -- 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: Fortune potty-mouth and those who demand it
> > On Jan 10 21:56, Gary R. Van Sickle wrote: > > > Oh, one more thing: I'd prefer it if any threats to > > 'censor' or 'ban' > > > me from this forum also be sent to this forum, and not to me > > > personally, so any hilariously blatant hypocrisy said > > threats may or > > > may not contain can be judged in the light of day, by the > > people, for > > > the people, and of the people. > > > > Who did that? Certainly neither Chris nor I > > No, it was neither you nor Chris. The name is not an unfamiliar one > however. > > > and there's > > nobody else who could "ban" you from the list. Can we see > > the mail please? You can obfuscate the addresses for now but > > I'm rather curious how such a hollow threat looks alike. > > > > I would be happy to show it to you; unfortunately, the sender wouldn't, and > would most certainly follow up any disclosure of the text in question with > more (apparently) empty threats. The sender has sent me a private email > "clarifying" the threat, and he is clearly still of the opinion that he > either has the ability to ban me or speaks for those who can. > > I have explicitly given the sender permission to post my private response to > his threats to this forum. Hopefully he is man enough to post them here for > all to examine, and this unseemly chapter in Cygwin history can be put to > rest. > > To the "Secret Admirer" in question: do you grant me the right to send the > email text in question, with any and all identifying marks... redacted... To > Corinna privately, as per her request? I would send the private response > mentioned above, with your text quoted, which I believe I quoted in full. > Please respond privately or publicly, however you see fit. But please > respond. You know who you are. > > I will cogitate over this and may send you the text with or without the > sender's permission, Corinna. If the sender indeed has no power in this > matter, I see little harm in doing so. If he does, well, as the French say, > c'est cerat, la vie. Or words to that effect. This is starting to get weird. -- 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: man prints JNROFF, KNROFF etc errors
> When I run man I get this printed before the page displays: > > $ man man > Unrecognized line in config file (ignored) > JNROFF LANG=ja_JP.UTF-8 /usr/bin/groff -Tnippon -mandocj > Unrecognized line in config file (ignored) > KNROFF /usr/bin/groff -Tkorean -mandoc > Unrecognized line in config file (ignored) > JNEQN /usr/bin/eqn -Tnippon > Unrecognized line in config file (ignored) > KNEQN /usr/bin/eqn -Tkorean > > If I comment out the offending lines from /usr/share/misc/man.conf it > fixes the problem. Is this the right solution? That's what I had to do. -- 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: su alternative for Win2k
> I was just installing postgreSQL and ran across the problem with > getting initdb to run as the postgres user. As expected, I could > neither su nor login to work. Searching the archives and the like > for a fix, the most often specified one was to use ssh. But as I > don't run sshd, and it seems a shame to have to run this just to > get an su-like behaviour, that wouldn't work for me. Now I'm curious. I haven't tried to search for bug reports on su in Cygwin. But it's never worked for me. I always figured that I was just doing something wrong, but it was never important enough to find out what it was and fix it-- I just used 'Run As' instead, as you suggest. So now I wonder, is it not just me? Is su in Cygwin broken for everyone? Thanks, A. -- 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: su alternative for Win2k
> On Fri, 28 Jan 2005, Andrew Schulman wrote: > > So now I wonder, is it not just me? Is su in Cygwin broken for > > everyone? > > <http://cygwin.com/faq/faq_3.html#SEC42> Thank you. As I said, I never bothered to look into it... Guess it's time to read the FAQs. Regards, Andrew. -- 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: Slow pipes after upgrade cygwin 1.5.12-1 -> 1.5.13-1
> Problem description: > Having a background job running, even in the lowest priority (low), > execution of pipes is extremly slow. Everything else seems to run fine. > > That's really weired, because at cygwin startup all scripts in > /etc/profile.d are sourced, which are using a lot of pipes. That results > in cygwin startup time up to minutes, if you have a lot of packages > installed. I've also observed very slow bash startup, on two different hosts after upgrade to cygwin 1.5.13-1. The first time I start bash after a reboot it pauses for several minutes without completing its startup scripts. If I interrupt the startup and exit bash, then start bash again, now it starts up in about the usual amount of time, until I reboot again. -- 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.dll 1.5.13-1: hangs
I just upgraded to cygwin 1.5.13-1 on two hosts, and am observing the same
problem on both: my bash startup hangs. I traced the problem to an
invocation of ssh-add in .bash_profile, with three keys as arguments.
The first time I run ssh-add after rebooting the host, it hangs. I can
leave it for 10 minutes, and it doesn't return. If I interrupt it and then
run the same command again, this time it completes successfully. This is
repeatable; every time I reboot and run ssh-add again, it hangs the first
time, I interrupt it, and then it runs normally again until the next
reboot.
I ran 'strace ssh-add $key1 $key2 $key3' immediately after rebooting; the
log is at http://home.comcast.net/~andrex/bugz/ssh-add-strace1.txt.
Execution continues normally until
286 46267 [main] ssh-add 2968 fhandler_socket::signal_secret_event:
signaled secret_event 90680872 90727139 [unknown (0x79C)] ssh-add 2968
_cygtls::remove: wait 0x
which doesn't return. In this log, 90 seconds later I interrupt ssh-add,
and the rest of the log is the process termination.
I then ran 'strace ssh-add $key1 $key2 $key3' again, and this time the
operation completed normally. The log is at
http://home.comcast.net/~andrex/bugz/ssh-add-strace2.txt. In this case the
same function call took about 1 second to complete, but it did return.
When I revert to cygwin 1.5.12-1, the problem does not occur. Output of
cygcheck -svr is attached.
Andrew.
Cygwin Configuration Diagnostics
Current System Time: Mon Mar 07 16:40:33 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: d:\usr\win\bin
d:\usr\share\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\sbin
C:\cygwin\usr\sbin
c:\WINDOWS
c:\WINDOWS\System32
c:\WINDOWS\ServicePackFiles\i386
c:\XPT
c:\DevStudio\VC98\Bin
c:\DevStudio\Common\Tools\WinNT
c:\DevStudio\Common\Tools
c:\DevStudio\Common\MSDev98\Bin
c:\ResKit
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1008(ASchulma) GID: 513(None)
513(None)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1008(ASchulma) GID: 513(None)
0(root) 513(None) 544(Administrators) 545(Users)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `D:\'
MAKE_MODE = `unix'
PWD = `/home/aschulma'
USER = `ASchulma'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\aschulma\Application Data'
CL = `-G5 -Og -Ox -Os -Gf -Gy -W3 -MD -nologo'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `D77E1BASCHULMA1'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `ssh'
DISPLAY = `:0.0'
EDITOR = `/win/c/EditPlus/EditPlus.exe'
GTK2_RC_FILES = `/home/aschulma/.gtkrc-2.0'
HEXEDITOR = `'
HISTFILE = `/home/aschulma/.bash_history'
HISTFILESIZE = `5000'
HISTIGNORE = `&:exit:ls:ll:[bf]g:nq'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `D77E1BASCHULMA1'
INCLUDE = `d:\usr\win\include;c:\DevStudio\VC98\include'
INFOPATH = `/usr/local/info:/usr/info:/usr/share/info'
JUNK = `*.aux *.bbl *.blg *.ilg *.lof *.log *.lot *.o *.obj *.toc *~ .*~ \#*
*.aps *.asv *.bsc *.idb *.ilk *.ncb *.obj *.opt *.pch *.pdb *.plg *.res *.sbr'
LD_RUN_PATH = `/home/aschulma/usr/win/lib:'
LESS = `-X -sme -j 10'
LIB = `d:\usr\win\lib;c:\DevStudio\VC98\lib'
LINK = `advapi32.lib comctl32.lib comdlg32.lib gdi32.lib kernel32.lib
shell32.lib user32.lib -nologo -opt:noWin98'
LOGONSERVER = `\\D77E1BASCHULMA1'
MANPATH =
`/home/aschulma/usr/share/man:/usr/local/man:/usr/man:/usr/share/man:/usr/X11R6/man'
MSDEV = `/win/c/DevStudio'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/win/k'
OS = `Windows_NT'
PAGER = `less'
PARINIT = `rTbgqR B=.,?_A_a Q=_s>|'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0207'
PROGRAMFILES = `/win/c'
PROMPT_CHARS = `$'
PS1 = `\[\033]0;\]\w\[\007\]\n\[\033[1;36m\]$PROMPT_CHARS\[\033[0m\] '
SESSIONNAME = `Console'
SHELL = `/usr/bin/bash'
SHLVL = `1'
SSH_AGENT_PID = `2772'
SSH_AUTH_SOCK = `/tmp/ssh-VoWwTL2748/agent.2748'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\aschulma\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `C:\DOCUME~1\aschulma\LOCALS~1\Temp'
UNISON = `/home/aschulma/.unison/D77E1BASCHULMA1'
UNISONBACKUPDIR = `/home/aschulma/.unison/D77E1BASCHULMA1/backup'
USERDOMAIN = `D77E1BASCHULMA1'
USERNAME = `aschulma'
USERPROFILE = `C:\Documents and Settings\aschulma'
WINDIR = `/win/c/WINDOWS'
WORKHOME = `/home/aschulma/EPA'
_ = `/usr/bin/cygcheck'
bashify = `() { local p;
for p in "$@";
do
eval '[ "$'$p'" ] && '$p'=$(cygpath -pu "$'$p'")';
done
}'
POSIXLY_CORRECT = `1'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Sol
Re: cygwin.dll 1.5.13-1: hangs
> On Mar 8 05:54, Andrew Schulman wrote: > > I just upgraded to cygwin 1.5.13-1 on two hosts, and am observing the same > > problem on both: my bash startup hangs. I traced the problem to an > > invocation of ssh-add in .bash_profile, with three keys as arguments. > > That should be solved in recent snapshots. Please try the latest one from > http://cygwin.com/snapshots/ No, the problem persists in the snapshot of 2005-03-08. strace shows that the first call to ssh-add hangs at the same place as before: 326 49929 [main] ssh-add 2804 fhandler_socket::signal_secret_event: signaled secret_event 92153532 92203461 [unknown (0xBFC)] ssh-add 2804 _cygtls::remove: wait 0x Here I interrupted after 92 seconds. When I interrupt and then rerun, this step completes successfully, although it takes almost an entire second to do so: 261 46126 [main] ssh-add 3116 fhandler_socket::signal_secret_event: signaled secret_event 999732 1045858 [main] ssh-add 3116 fhandler_socket::connect: Receiving eid credentials failed: Win32 error 231 -- 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: cygwin.dll 1.5.13-1: hangs
> In my case, this snapshot does not fix the problem. Now instead of > ssh-add hanging the first time it's run before prompting for the > passphrase, it now hangs *every* time after prompting for the > passphrase. I can confirm this. I'm now running with cygwin1-20050308.dll-1. All invocations of ssh-add now hang. Here's a snippet of strace output from the first invocation after a reboot: 184 47362 [main] ssh-add 2980 fhandler_socket::signal_secret_event: signaled secret_event 36925366 36972728 [unknown (0xC24)] ssh-add 2980 _cygtls::remove: wait 0x where I interrupted after 36 seconds. This is the same as with version 1.5.13. But after I interrupt and then rerun, it hangs in a different place: 179 45744 [main] ssh-add 3168 fhandler_socket::signal_secret_event: signaled secret_event 277 46021 [main] ssh-add 3168 fhandler_socket::connect: Received eid credentials: pid: 2868, uid: 1008, gid: 513 38 95525 [main] ssh-add 3168 readv: readv (3, 0x22E440, 1) blocking, sigcatchers 0 33 95558 [main] ssh-add 3168 readv: no need to call ready_for_read 28241644 28337202 [unknown (0xCEC)] ssh-add 3168 _cygtls::remove: wait 0x where again I interrupted after 28 seconds. Full output of cygcheck - svr and 1st and 2nd invocations of 'strace ssh-add $key1 $key2 $key3' are at http://home.comcast.net/~andrex/cygwin/cygcheck-svr.txt http://home.comcast.net/~andrex/cygwin/ssh-add-strace1.txt http://home.comcast.net/~andrex/cygwin/ssh-add-strace2.txt cygcheck -svr is the same as before, except for the version of cygwin1.dll. Note that I'm no longer running ssh-add as part of my bash startup scripts. I've suppressed that, and am now running a simple 'ssh-add $key1 $key2 $key3' from the shell prompt. The result is the same. > Plus, if I try to kill ssh-agent with "eval `ssh-agent -k`", > that hangs too. Nothing will kill the agent. Not even kill -9. I can't confirm this. It works fine for me. Just to add to the fun though, I also find that one of my otherwise long-standing stable apps, autossh, now crashes within five minutes of boot every time, with 1.5.13 or later. I'll document this ASAP and submit it under a different thread. -- 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-2005-03-08.dll-1: access violation - cygcheck-svr.txt [1/1]
I'm running autossh-1.2g-4 with cygwin1-2005-03-08.dll-1. autossh has
been quite stable for me with versions of cygwin1.dll up to and
including 1.5.12-1. But with 1.5.13 and later snapshots, it crashes
reliably 5 minutes after starting, right at the time when it wakes up to
do some polling of its child ssh process.
Here is combined stdout/stderr output from 'strace autossh':
2005/03/09 14:36:25 autossh[3208]: checking for grace period, tries = 0
2005/03/09 14:36:25 autossh[3208]: starting ssh (count 1)
2005/03/09 14:36:25 autossh[3208]: ssh child pid is 3168
2005/03/09 14:36:25 autossh[3208]: check on child 3168
2005/03/09 14:36:25 autossh[3168]: execing /usr/bin/ssh
2005/03/09 14:36:25 autossh[3208]: set alarm for 300 secs
300115499 [main] autossh 3208 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
300116527 [main] autossh 3208 open_stackdumpfile: Dumping stack trace to
autossh.exe.stackdump
Full strace output and the stackdump (FWIW) are posted at
http://home.comcast.net/~andrex/cygwin/autossh-strace.txt.bz2
http://home.comcast.net/~andrex/cygwin/autossh.exe.stackdump
Output of cygcheck -svr is attached.
Andrew.
Cygwin Configuration Diagnostics
Current System Time: Wed Mar 09 13:54:30 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1
Path: d:\usr\win\bin
d:\usr\share\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\sbin
C:\cygwin\usr\sbin
c:\WINDOWS
c:\WINDOWS\System32
c:\WINDOWS\ServicePackFiles\i386
c:\XPT
c:\DevStudio\VC98\Bin
c:\DevStudio\Common\Tools\WinNT
c:\DevStudio\Common\Tools
c:\DevStudio\Common\MSDev98\Bin
c:\ResKit
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1008(ASchulma) GID: 513(None)
513(None)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1008(ASchulma) GID: 513(None)
0(root) 513(None) 544(Administrators) 545(Users)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `D:\'
MAKE_MODE = `unix'
PWD = `/home/aschulma'
USER = `ASchulma'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\aschulma\Application Data'
CL = `-G5 -Og -Ox -Os -Gf -Gy -W3 -MD -nologo'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `D77E1BASCHULMA1'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `ssh'
DISPLAY = `:0.0'
EDITOR = `/win/c/EditPlus/EditPlus.exe'
GTK2_RC_FILES = `/home/aschulma/.gtkrc-2.0'
HEXEDITOR = `'
HISTFILE = `/home/aschulma/.bash_history'
HISTFILESIZE = `5000'
HISTIGNORE = `&:exit:ls:ll:[bf]g:nq'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `D77E1BASCHULMA1'
INCLUDE = `d:\usr\win\include;c:\DevStudio\VC98\include'
INFOPATH = `/usr/local/info:/usr/info:/usr/share/info'
JUNK = `*.aux *.bbl *.blg *.ilg *.lof *.log *.lot *.o *.obj *.toc *~ .*~ \#*
*.aps *.asv *.bsc *.idb *.ilk *.ncb *.obj *.opt *.pch *.pdb *.plg *.res *.sbr'
LD_RUN_PATH = `/home/aschulma/usr/win/lib:'
LESS = `-X -sme -j 10'
LIB = `d:\usr\win\lib;c:\DevStudio\VC98\lib'
LINK = `advapi32.lib comctl32.lib comdlg32.lib gdi32.lib kernel32.lib
shell32.lib user32.lib -nologo -opt:noWin98'
LOGONSERVER = `\\D77E1BASCHULMA1'
MANPATH =
`/home/aschulma/usr/share/man:/usr/local/man:/usr/man:/usr/share/man:/usr/X11R6/man'
MSDEV = `/win/c/DevStudio'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/win/c'
OS = `Windows_NT'
PAGER = `less'
PARINIT = `rTbgqR B=.,?_A_a Q=_s>|'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0207'
PROGRAMFILES = `/win/c'
PROMPT_CHARS = `$'
PS1 = `\[\033]0;\]\w\[\007\]\n\[\033[1;36m\]$PROMPT_CHARS\[\033[0m\] '
SESSIONNAME = `Console'
SHELL = `/usr/bin/bash'
SHLVL = `1'
SSH_AGENT_PID = `2896'
SSH_AUTH_SOCK = `/tmp/ssh-SJOXqL2868/agent.2868'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\aschulma\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `C:\DOCUME~1\aschulma\LOCALS~1\Temp'
UNISON = `/home/aschulma/.unison/D77E1BASCHULMA1'
UNISONBACKUPDIR = `/home/aschulma/.unison/D77E1BASCHULMA1/backup'
USERDOMAIN = `D77E1BASCHULMA1'
USERNAME = `aschulma'
USERPROFILE = `C:\Documents and Settings\aschulma'
WINDIR = `/win/c/WINDOWS'
WORKHOME = `/home/aschulma/EPA'
_ = `/usr/bin/cygcheck'
bashify = `() { local p;
for p in "$@";
do
eval '[ "$'$p'" ] && '$p'=$(cygpath -pu "$'$p'")';
done
}'
POSIXLY_CORRECT = `1'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/home/aschulma
(default) = `d:'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/home/aschulma/EPA
(default) = `e:'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts
v2\/home/aschulma/software/ma
Re: cygwin.dll 1.5.13-1: hangs
> > 184 47362 [main] ssh-add 2980 fhandler_socket::signal_secret_event: > >signaled secret_event > >36925366 36972728 [unknown (0xC24)] ssh-add 2980 _cygtls::remove: wait > >0x > > Do you actually have an ssh-agent running at this point? If so, try > "strace -ofoo -p " on ssh-agent's pid to see what it is doing while > ssh-add is attempting to talk to it. Yes, I do. OK, here is strace output from new 1st and 2nd runs of ssh- add after reboot, and from ssh-agent running at the same time: http://home.comcast.net/~andrex/cygwin/ssh-add-strace1.txt http://home.comcast.net/~andrex/cygwin/ssh-add-strace2.txt http://home.comcast.net/~andrex/cygwin/ssh-agent-strace.txt -- 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: cygwin.dll 1.5.13-1: hangs
> Out of curiosity, do you run your shell in an xterm window? If I run > from the command line it works fine, but in an xterm window it hangs. No, I just run C:\cygwin\bin\bash.exe --login. The default console window opens. -- 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: cygwin.dll 1.5.13-1: hangs
> Just to clarify. When ssh-add is hanging, the ssh-agent process still > exists? Yes. -- 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: ssh-add hangers -- please try the latest snapshot
> On Thu, Mar 10, 2005 at 08:24:25AM -0500, Chuck wrote: > >Christopher Faylor wrote: > >>Corinna identified a couple of problems and checked in some fixes which > >>may solve the problem with ssh-add hanging. > >> > >>Please try the latest snapshot and report success for failure here. > >> > >>http://cygwin.com/snapshots/ > > > >Seems to have fixed the problem. Thanks Corinna, Christopher, Andrew, > >and anyone else involved. > > Andrew, does this solve your problem? Yes, the hang is gone when I use 2005-03-09 snapshot. And, the formerly troublesome call now returns in < 1 ms, instead of ~1 s as before. As Chuck said, thanks to you and Corinna for pursuing and fixing this. > I have been puzzling over the segv that you reported trying to figure > out how it could possibly happen. I checked in a half-hearted attempt > to fix it but I'm not too confident that it will rectify anything. It's > dying in networking code at a very strange place. Agreed. I can tell you that the problem isn't fixed in the 2005-03-09 snapshot, but I'll continue discussion of that problem in the other thread. Andrew. -- 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: ssh-add hangers -- please try the latest snapshot
> Hi All... > > With the latest snapshot, I can not see the problem now. > > It also seemd to take a long time sometimes with the previous snapshot > (March 4) in ssh-add. That also seems better now. But I really don't have > enough data to say much here...it just seems better. You're right-- after the first invocation, ssh-add would work, but strace showed that the troublesome call would take about 1 s to return. That time is now < 1 ms. -- 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: autossh crash with 20050314 and earlier cygwin1.dll
> 0065E938 61093A1F (6112B460, 7974742F, 61120031, 6974616D) > malloc.cc:3952 > nextchunk = chunk_at_offset(p, size); > nextsize = chunksize(nextchunk); > > > yeesh. nasty heap corruption leading to bad nextchunk pointer and an > exception when it is dereferenced in the attempt to find nextsize. > happening in a realloc call. ugly. it's going to be hard to track down; > whatever is causing the corruption may be taking place an arbitrary amount > of time prior to when the exception happens, and not necessarily in the same > thread either. Would the job be easier in my case, where I have a repeatable crash? I provided strace output in the earlier thread about my autossh problems, but haven't tried using any debug builds of cygwin1.dll. I'm not conversant with debuggers, but I have used gdb before and could work my way through it. Let me know if this would be useful, and how best to go about it. Of course there's no guarantee that my crash and David's have the same cause, but they might well and it would be as good a place as any to start. -- 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: autossh crash with 20050314 and earlier cygwin1.dll [autossh maintainer please note]
> The problem is that autossh is freeing the return value of > gethostbyname(). I can't find any reference which says that is a > acceptable thing to do. It certainly screws up cygwin, and I can't > think of any way to avoid having it screw up cygwin. Maybe it won't > screw up other systems since they may not malloc the return value of > gethostbyname. I dunno. OK. (hangs head) I have to take the blame for this, because as it happens I contributed that bit of code. Forgive my simplicity on this point, but it seemed like good memory heigene-- free up the memory that gethostbyname() allocated, once I was done with it. Looking back now at the man page for gethostbyname() (in Linux, there's no Cygwin man page AFAIK), it seems unclear on this point: the NOTES section says "The functions gethostbyname() and gethostbyaddr() *may* return pointers to static data, which may be overwritten by later calls." (emphasis added) This may have been a dumb mistake, or not. Obviously if the memory is static, I shouldn't free() it, but the docs are unclear about whether it is or not. Should I infer that I should not free() memory allocated by a function that I call unless the man page specifically says to? Or just that it's best not to free() it if it might be static? This seems like a complicated issue and any pointers for this journeyman network programmer would be welcome. Probably OT for this list, though. > I haven't run an exhaustive test, but the patch below seems to fix this > problem. Confirmed, it fixes my crash here with cygwin1.dll snapshot of 2005-Mar- 11. > Could the autossh maintainer look into getting this applied upstream? Done. I'll release a new version shortly. Andrew. -- 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: autossh crash with 20050314 and earlier cygwin1.dll
> GOK why it works on glibc-based systems, but I guess it must, or the > problem would surely have cropped up before. Hm.. Simple: that part of the code is contained in an #ifdef HAVE_NO_ADDRINFO ... #endif block, and so is only built on systems without a getaddrinfo () function. That includes Cygwin, not glibc, and maybe no other systems in common use. -- 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: autossh crash with 20050314 and earlier cygwin1.dll [autossh maintainer please note]
> Generally speaking, it is whoever mallocs memory that has the > responsibility for freeing it. If your app mallocs it, your app should free > it; if the library mallocs it, the library should free it. > > In some cases, the ownership of a bit of memory (or any other resource) > may be transferred; in those cases, the responsibility for deallocation is > transferred along with the ownership. > > But that does not happen without a clear statement in the interface / > documentation. A function that returns a pointer to some data in memory is > giving you just that, and no more: a pointer to some data in memory. Only > if the specification of the function explicitly states that the caller gets > ownership of the resource should your code assume it has any rights over it > whatsover. If the interface doesn't say so, then you should assume nothing > - not just that you can't free (...) it, but you should also assume that you > aren't allowed to overwrite the memory block or change its contents or do > anything other than examine and/or copy it. OK, thank you. This seems clear. I've sent the patch for this problem upstream, and the corrected Cygwin package will be out shortly. Andrew. -- 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: Spaces in Paths
> >> mysqldump='/cygdrive/c/program\ files/mysql/MySQL\ Server\ > >> 4.1/bin/mysqldump.exe' > >> > >> I get "/cygdrive/c/program\: No such file or directory..." > >> > >> Is this just hard luck? > > > >Nope, just the way the quoting rules work. You've already quoted the spaces > >by > >using the ' character around it. Either remove the \s or remove the 's. > Jonathon, > I believe I've tried all combinations! with single, double quotes, with and > w/o backslashes You should find and study a good reference on shell quoting. I first learned about it from chapter 9 of Unix Power Tools, but I'm sure the bash manual also describes it well. Unfortunately, in general it can be quite a PITA to keep track of file names with spaces in them, especially when you start working with lists of file names. But with practice it gets easier. Good luck, Andrew. -- 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: maintaining bash
> There is one potential problem in that we may need to adapt Pierre's > patch to prevent problems with pid reuse to 3.0 if it is released. Besides that, looking at ftp://ftp.gnu.org/pub/gnu/bash/bash-3.0- patches/, I see 16 patches. I hope all of those will be applied to a Cygwin bash 3.0 package. Unfortunately, none of those patches appears to fix the extra-space- after-the-prompt bug, reported at http://mail-index.netbsd.org/pkgsrc- bugs/2005/03/25/0002.html. I just built bash 3.0 from source, and yes it does compile OOTB, but the extra space bug, which was reported to have been fixed in 2.05, is back. http://www.cygwin.com/ml/cygwin/2003- 09/msg00926.html says the bug will be fixed in 2.05, but I haven't seen the patch there or anywhere else to fix it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: cygutils-1.2.7-1
>$ head -1 /usr/bin/rename >#!/usr/bin/perl -w Yes, Debian includes a perl script /usr/bin/rename, which seems more powerful than Cygwin rename: NAME rename - renames multiple files SYNOPSIS rename [ -v ] [ -n ] [ -f ] perlexpr [ files ] DESCRIPTION "rename" renames the filenames supplied according to the rule specified as the first argument. The perlexpr argument is a Perl expression which is expected to modify the $_ string in Perl for at least some of the filenames specified. If a given filename is not modified by the expression, it will not be renamed. If no filenames are given on the command line, filenames will be read via standard input. For example, to rename all files matching "*.bak" to strip the extension, you might say rename 's/\.bak$//' *.bak To translate uppercase names to lower, you'd use rename 'y/A-Z/a-z/' * This is a more powerful approach, because it uses Perl regexps. OTOH, that makes it hard for non-Perl initiates to use. Maybe this rename could also be included in Cygwin under a different name, say rename2 or prename. A. -- 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: Unison 2.10.2 fast update check broken?
Hi Marcus. Thanks for the report. > Seems that Cygwin port of the unison file synchronizer does not do the > -fastcheck very well. Transcript follows: > > # Start of transcript > > # creates archives for first time > $ cd /tmp ; touch a b ; /bin/unison-2.10.2 ./a ./b > ... > > $ touch a > > $ /bin/unison-2.10.2 -fastcheck true -times -debug verbose ./a ./b > ... > > # now output shows that file contents is checked, ie. the "Double-check > # possibly updated file" line, which is correct, since we did a touch > > $ /bin/unison-2.10.2 -fastcheck true -times -debug verbose ./a ./b > ... > > # BUG: outputs again the "Double-check possibly updated file" line for file > # 'b', ie. file content is checked even if no mods. > > # End of transcript I think this is the expected behavior, since a and b have the same contents. When Unison observes the different timestamps, it flags the files as possibly different and prints the "Double-check" message. Then it looks more carefully, and determines that their contents are in fact the same, so no update is propagated. That includes the timestamps, even though you specified -times. So then when you run the operation again, the same thing happens because nothing was changed on the previous run. The effect of -times is to make Unison synchronize the timestamps when an update is needed because the file contents are different. It doesn't make the timestamps sufficient to determine that files are different. At least, that's my reading of the manual. > The above transcript functions as > expected using linux or native Win32 unison builds. Hm, are you sure? If so, then that blows away my carefully constructed explanation above. I've looked at the set of patches that I applied to get Unison 2.10.2 running in Cygwin, and I don't see anything there that would obviously affect the -fastcheck option. But it's possible, and if you show me the evidence I'll look into it. HTH, Andrew. -- 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: screen: fhandler_socket::close() fails w/ Cygwin >= 1.5.15
> On Tue, May 17, 2005 at 01:50:06PM -0400, [EMAIL PROTECTED] wrote: >>_The socket is no longer a socket._ > > Try a snapshot. Hm, and after all that detailed reporting... The problem is fixed with the 20050516 snapshot. I'll continue testing screen. Thanks, A. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New package: stow
> Does stow have support for hard links at all? No, not at present. > If not is that an easy > thing to add in? It probably is, although I can't spend any time on it in the foreseeable future. > Such an option would make stow more useful on Cygwin, IMHO. I think you're right, for the following reasons. One, as I said in the announcement, Cygwin implements symlinks as Windows shortcuts, which are broken. Therefore, stow will only be useful for installing software that is used exclusively within Cygwin (which interprets the shortcuts to emulate POSIX behavior) and that doesn't install any DLLs (since Windows won't interpret the symlinks correctly). Two, Cygwin implements hard links as file copies. Windows file systems don't support hard links, so this is probably the best that can be done. So 'ln a b' is really the same as 'cp -p a b'. Now that approach has obvious disadvantages (it uses twice the disk space; changes in either file aren't reflected in the other, since they're different files), but for software installation it would have the advantage of solving the symlink problem. Installed files (including DLLs) would just be copied into the installation directory, where Windows can use them. The original, stowed copy (e.g. /usr/local/stow/emacs) would become superfluous, except as a map of which files to delete if you want to uninstall the package. Also, the problem of modifications to the target not being reflected in the source probably isn't very important for software installation, since the package files don't get changed much. So, if someone wanted to pursue this, I think it would be useful. Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New package: stow
>> Two, Cygwin implements hard links as file copies. Windows file systems >> don't support hard links, so this is probably the best that can be done. >> So 'ln a b' is really the same as 'cp -p a b'. > > Huh? NTFS supports hardlinks from the beginning and Cygwin supports > creating hardlinks on NTFS since... oh, lemme see... 1997. Okay. My mistake-- I'm using VFAT here. -- 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: New call: Please test latest snapshot
> Just for the records: It should also fix the socket problem on > postgresql, loosing the socket file attributes on touch(). Yes, I had the same problem with screen, and it is fixed in 2005-05-17. -- 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: Command to move groups of files
> Somone a month or so ago posted a list of little known Cygwin
> commands, and in that list was a cool command that allowed you
> to rename a list of files, like thus:
>
> cmd First*.* Second*.*
>
> which would rename all files starting with "First" to be "Second".
> I used this command a bit, and then promptly forgot about it until
> I really needed to use it yesterday.
>
> Could someone remind me of the name of that command?
Yes, I remember the command. Its name is:
for ff in First*.* ; do
mv $ff Second${ff#First}
done
Works for me, I use it all the time :)
--
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: Running cygwin service via cygrunsrv under account without password in Win XP Pro - impossible?
> cygrunsrv: Error starting a service: StartService: Win32 error 1069: > The service did not start due to a logon failure. > > This happens only if my account has no password. Once I set any password - > it works great. Autossh starts under cygrunsrv as a service under my account > and sets all my ssh tunnels and everything works perfect. I remove password, > then try every possible way to tell Windows to run it under account without > password - no luck. Error 1069 again and again. > > My account has administrative privileges and "logon as a service" privilege. > I use Windows XP Professional. The cygwin version is the latest (installed > two days ago). > > cygrunsrv.README says: > > -w, --passwd > Optional password for user. Only needed if a user is given. If a > user has an empty password, enter `-w ' with no . > cygrunsrv -I svc_name -p /usr/bin/svc.exe -u foo -w "" Isn't '-w ""' different from just '-w'? In other words, cygrunsrv.README is telling you to use no password, while you're giving it an empty password, which is different. I dunno, but it's worth a try. > This is what I have tried, plus I tried omitting -w option at all and just > pressing Enter key when asked for password by cygrunsrv interactively. I > also tried setting empty password in the Services control panel, by going to > the service properties and then setting my account and empty password in the > LogOn tab there. All with the same result - error 1069. > > Here's the cygrunsrv command lines I've tried (neither works): > > cygrunsrv -I ubcgw -p /bin/autossh -t manual -a '-M 0 -L 143:imap:143 -L > 25:smtp:25 mail.ubc.ca' -e AUTOSSH_NTSERVICE=yes -u vadym -w "" > cygrunsrv -I ubcgw -p /bin/autossh -t manual -a '-M 0 -L 143:imap:143 -L > 25:smtp:25 mail.ubc.ca' -e AUTOSSH_NTSERVICE=yes -u vadym So you could try the first one again, leaving the '-w' but omitting the "". Another option is to run the service as user SYSTEM. This is what I do, and I've never had any trouble. But of course you're right to try to run it under a lower-privilege account. Good luck, and let us know what you find out. Andrew. -- 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: screen
>> Yes, the reattachment problem is now solved AFAICT, using Cygwin 1.5.17 or >> later. Most of it works just fine, but there's one problem that I haven't >> solved yet: when you detach a session, it stays bound to its parent >> shell. So if you then try to exit the parent shell, it hangs. You can >> terminate the parent shell, but then screen exits too. Obviously this >> takes away one of the big advantages of screen, which is the ability to >> detach a session, leaving it running in the background, and then reattach >> later from a different terminal. > > hmm I have not had that problem? I run rxvt's with bash and can exit all > terminals leaving no bash process but screen lives on. I can then fire > up another shell and re-connect to screen and any jobs it has running. > (ie it works just like it should!) Interesting. Okay, I hadn't noticed this before, but the problem does seem to be particular to the Cygwin console. It doesn't occur with rxvt. Also, it doesn't occur in the Cygwin console if I start a subshell first, and invoke screen from there. Maybe useful to know. Still, I do want to solve the problem before I release screen. -- 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: Cygwin and firewalls
> I am wondering if there is a firewall that coexists with Cygwin well. > IIRC, there were complaints about Norton software and about some other > firewalls too. What would you recommend me? > > I ask because I've never had to use firewall before (my home box is behind > NAT in a secure network) and I have no experience with Windows firewalls. > I've just bought a laptop and a firewall seems to be necessary in this > case. Why is this a Cygwin question? A firewall is a firewall. Network applications, both Cygwin and non-Cygwin, have to deal with it. I don't know what a Cygwin-hostile firewall would look like. -- 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: 1.5.17: problem building GNU screen
> I found a problem building GNU screen on cygwin 1.5.17.
> Invoking ./configure leads to produce below error message.
>
>>rm: cannot remove `conftext.exe': Permission denied.
IIRC I encountered this problem during the test for a broken FIFO
implementation. As it turns out, Cygwin's FIFO implementation is broken
(http://cygwin.com/ml/cygwin-apps/2005-04/msg00163.html), but the test in
configure doesn't detect this. So, my solution was just to remove this
test from the configure script and set fifo= . This also solved the
leftover process problem. Try applying the attached patch, and rerunning
configure.
Also, a test package of screen is available. You may find it easier just to
run it instead. See http://cygwin.com/ml/cygwin/2005-06/msg00608.html for
a recent update.
Good luck,
Andrew.
diff -ur screen-4.0.2.orig/configure screen-4.0.2/configure
--- screen-4.0.2.orig/configure 2003-12-05 08:46:54.0 -0500
+++ screen-4.0.2/configure 2005-05-02 10:30:20.0 -0400
@@ -4156,206 +4156,15 @@
fi
rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
-{ echo "$as_me:$LINENO: checking fifos..." >&5
-echo "$as_me: checking fifos..." >&6;}
-if test "$cross_compiling" = yes; then
- { { echo "$as_me:$LINENO: error: cannot run test program while cross
compiling
-See \`config.log' for more details." >&5
-echo "$as_me: error: cannot run test program while cross compiling
-See \`config.log' for more details." >&2;}
- { (exit 1); exit 1; }; }
-else
- cat >conftest.$ac_ext <<_ACEOF
-#line $LINENO "configure"
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-#include
-#include
-#include
-
-#ifndef O_NONBLOCK
-#define O_NONBLOCK O_NDELAY
-#endif
-#ifndef S_IFIFO
-#define S_IFIFO 001
-#endif
-
-char *fin = "/tmp/conftest$$";
-
-main()
-{
- struct stat stb;
-#ifdef FD_SET
- fd_set f;
-#else
- int f;
-#endif
-
- (void)alarm(5);
-#ifdef POSIX
- if (mkfifo(fin, 0777))
-#else
- if (mknod(fin, S_IFIFO|0777, 0))
-#endif
-exit(1);
- if (stat(fin, &stb) || (stb.st_mode & S_IFIFO) != S_IFIFO)
-exit(1);
- close(0);
-#ifdef __386BSD__
- /*
- * The next test fails under 386BSD, but screen works using fifos.
- * Fifos in O_RDWR mode are only used for the BROKEN_PIPE case and for
- * the select() configuration test.
- */
- exit(0);
-#endif
- if (open(fin, O_RDONLY | O_NONBLOCK))
-exit(1);
- if (fork() == 0)
-{
- close(0);
- if (open(fin, O_WRONLY | O_NONBLOCK))
- exit(1);
- close(0);
- if (open(fin, O_WRONLY | O_NONBLOCK))
- exit(1);
- if (write(0, "TEST", 4) == -1)
- exit(1);
- exit(0);
-}
-#ifdef FD_SET
- FD_SET(0, &f);
-#else
- f = 1;
-#endif
- if (select(1, &f, 0, 0, 0) == -1)
-exit(1);
- exit(0);
-}
-
-_ACEOF
-rm -f conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- echo "- your fifos are usable" 1>&6
- fifo=1
-else
- echo "$as_me: program exited with status $ac_status" >&5
-echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-( exit $ac_status )
+# Cygwin patch:
+# Cygwin's fifo implementation is broken; see
+# http://cygwin.com/ml/cygwin-apps/2005-04/msg00163.html.
+# Unfortunately, the "broken fifo implementation test" that was in this
+# script doesn't detect this, so just short-circuit the whole thing here.
+echo "$as_me: checking fifos..." >&6
echo "- your fifos are not usable" 1>&6
-
-fi
-rm -f core core.* *.core gmon.out bb.out conftest$ac_exeext
conftest.$ac_objext conftest.$ac_ext
-fi
-rm -f /tmp/conftest*
-
-if test -n "$fifo"; then
-{ echo "$as_me:$LINENO: checking for broken fifo implementation..." >&5
-echo "$as_me: checking for broken fifo implementation..." >&6;}
-if test "$cross_compiling" = yes; then
- { { echo "$as_me:$LINENO: error: cannot run test program while cross
compiling
-See \`config.log' for more details." >&5
-echo "$as_me: error: cannot run test program while cross compiling
-See \`config.log' for more details." >&2;}
- { (exit 1); exit 1; }; }
-else
- cat >conftest.$ac_ext <<_ACEOF
-#line $LINENO "configure"
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-#include
-#include
-#include
-#include
-
-#ifndef O_NONBLOCK
-#define O_NONBLOCK O_NDELAY
-#endif
-#ifndef S_IFIFO
-#define S_IFIFO 001
-#endif
-
-char *fin = "/tmp/conftest$$";
-
-main()
-{
- struct timeval tv;
-#ifdef FD_SET
- fd_set f;
-#else
- int f;
-#endif
-
-#ifdef POSIX
- if (mkfifo(fin, 0600))
-#else
- if (mknod(fin, S_IFIFO|0600, 0))
-#endif
-exit(1);
- close(0);
- if (o
Re: Cygwin and firewalls
>> Why is this a Cygwin question? A firewall is a firewall. Network >> applications, both Cygwin and non-Cygwin, have to deal with it. I don't >> know what a Cygwin-hostile firewall would look like. > > Cygwin uses sockets to implement many of its functions, such as IPC. > Some overzealous firewalls install themselves deeply into the winsock > stack (I believe it's called 'layered service provider' API) and install > hooks throughout. This can cause things to break if the firewall > implementation is not done properly and without bugs, or causes the > semantics of socket operations to change. See for example, the threads > about crappy VPN clients causing cygwin programs to hang, or the > Zonealarm firewall causing the X11 server to hang at startup. Sadly the > archives are littered with examples of poorly written firewall-type > software that causes things to break, so it's not such a stupid > question. OK, thanks. Learn something new every day. -- 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: Command not found eventhough it is on one of the PATH directories
> /home/corrada > 6 % jython.bat > jython.bat: Command not found. What does 'which jython.bat' tell you? -- 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/
OCaml library location error
I've installed ocaml 3.08.1-1. $ ocamlc -v The Objective Caml compiler, version 3.08.1 Standard library directory: /usr/local/stow/ocaml/lib/ocaml The library location is wrong; it should be /usr/lib/ocaml. This breaks some compilations of course. Andrew. -- 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: OCaml library location error
> $ ocamlc -v > The Objective Caml compiler, version 3.08.1 > Standard library directory: /usr/local/stow/ocaml/lib/ocaml > > The library location is wrong; it should be /usr/lib/ocaml. This breaks > some compilations of course. My mistake: I had set OCAMLLIB earlier in my environment, then forgot. Sorry. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
how to link without libutil.so? [repost]
I'm trying to build Unison version 2.9.99. Compilation succeeds, but the link step fails with /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld: cannot find -lutil after running a gcc command that includes '-lutil'. I've searched the Cygwin packages, and it does seem that there's no file libutil.a or libutil.so in any of them. On other platforms, this is a standard library. So is there some other library that I should use in place of libutil.* on Cygwin? I tried 'ln -s libcygwin.a /usr/lib/libutil.a' (what the hell, it was worth a shot) but it failed. Other people have asked about this same problem in other forums, but I haven't seen any of them get an answer. Thanks, Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to link without libutil.so? [repost]
>>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld: >>cannot find -lutil > > As you noted, the file doesn't exist in the cygwin distribution. It's > possible that you could just get by with removing it from the link line > entirely since it looks like most of the functions in this library are > in cygwin1.dll. No, I tried that already. The link still fails. > Otherwise, you'll have to come up with workarounds for the missing > functions. OK, thanks. I guess I'll have to start digging in. A. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to link without libutil.so? [repost]
> "the link still fails" provides almost zero useful information. True. > Since Corinna went to some effort to add libutil functionality to the > cygwin DLL a while ago and since I can't see any functions in libutil.so > which are missing from cygwin1.dll, I don't see why this didn't work. Okay, I went back and tried this again, in order to provide the error message. Instead I solved the problem. The line in question in the Makefile was CLIBS+=-cclib -lutil The first time I looked at this line, in my simplicity I only commented out the '-lutil', and the link failed (can't remember the error message now). This time I commented out the whole line, and the linking completed successfully. So yes, it seems that libutil.so is taken care of by cygwin1.dll. The real problem here is that the latest Unison Makefile isn't correctly detecting that it's building in a Cygwin environment. That's why it executed the line above. I'll send a patch to the Unison developers. Thanks for your help. Andrew. -- 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: where is cygwin1.dll available?
find / -name cygwin1.dll -- 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/
typo on cygwin.com
http://cygwin.com/faq/faq_1.html, "Is it free software?": "... read the copyright section of the FAQ more more information ..." -- 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/
typo on cygwin.com (#2)
http://cygwin.com/faq/faq_1.html#SEC5: "If you are looking for the a version number ..." -- 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: gtk 2?
> I need gtk 2 to get Dia (an open source diagramming package to displace > Microsoft Visio). (http://www.gnome.org/projects/dia/) Consider also xfig, which is already in Cygwin and which Dia looks very similar to. -- 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: Latest snapshot with XP SP2 and unison and cvs
> I just updated an xp machine to sp2 and unison-2.9.1 (the win32 version) > using ssh (cygwin) started hanging. I have done a clean install of cygwin > and am running with the 16sep snapshot. cvs (cygwin) works fine with ssh. > unison hangs with ssh. > > Because win32 unison will not run under bash, I opened a cygwin bash window, > did an strace of cmd > and then ran unison. The strace is attached. Karl, you may want to try a later version of Unison. 2.9.1 is pretty old now, and although I don't know about that version specifically, I know that there have been "hanging" bugs in other versions. A Cygwin version of Unison 2.10.2 has just been released; you should be able to find it in the Cygwin setup utility. However, the archive format has changed, so you will have to be using version 2.10.x (I believe) on both hosts or Unison will complain. It will also have to resync its archive lists. Good luck, Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Two new mailing lists
> As somebody who uses gmane instead of email lists, I cannot find these > new lists on gmane. Any idea if they will be automagically included or > does somebody need to notify the gmane site? Someone needs to ask the gmane admins to add the lists. -- 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] fileutils: ln --target-directory with just one target fails - cygcheck-svr.out [1/1]
$ ls -l dir1 $ ln -fs --target-directory=dir1 ../test.txt ln: `dir1/.': cannot overwrite directory $ ls -l dir1 total 0 lrwxrwxrwx1 ASchulma None 11 Oct 14 16:42 test.txt -> ../test.txt What seems to happen here is that when ln --target-directory is given only one target file (here test.txt), it works on the first one, then 'sees' . as a second target. Who is the Cygwin maintainer of fileutils? I can't find any Cygwin doc files for it. Should I submit this bug upstream? Andrew. cygcheck-svr.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: Cygwin problem
> I have a problem with cygwin. I wanted to install on my PC cygwin with the > UNIX text mode. > I don't know why because I tried it many times but cygwin after installing is > working allways > in the DOS text mode. Furthermore, the most basic functions like "ls" or > "dir" aren't > working. I need to cygwin for NS-2 (Network Simulator). Please help me!!! In addition to what Larry said, please consider writing a useful subject. "Cygwin problem" could describe 90% of the traffic on this list. -- 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 2.05 vs. 3.0 Prompt Behavior
> I updated my Cygwin installation this morning and picked up the new > version of Bash (3.0-7). When I started a new shell (running under > rxvt) I was suprised to see that my prompt displayed differently than > before the upgrade. I use the following prompt > > PS1='\[\e]0;[EMAIL PROTECTED] [EMAIL PROTECTED] ' > > The difference is the display of the portion that is not put in the > title bar, with Bash 2.05 the prompt was (ignoring the tick marks, which > are only included to the trailing whitespace) '[EMAIL PROTECTED] ', while > with Bash 3.0 the prompt is '[EMAIL PROTECTED] '. Note the extra space at > the end with 3.0. If I remove the space, the dollar sign is doubled, > i.e. '[EMAIL PROTECTED]', if I replace the last space in the PS1 value > with someother character, then that character is doubled. > > I do not see this behavior if I use the default value of PS1 from > /etc/profile. > > I have tried googling 'bash 3.0 prompt' and did not find any obvious > help. Has anybody else seen this behavior? The 'extra space in the prompt' bug is well known; see e.g. http://sources.redhat.com/ml/cygwin/2005-04/msg00325.html and http://sourceware.org/ml/cygwin-apps/2005-04/msg00036.html. -- 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: The perils of editing .bashrc
> Is it advisable to edit one's .bashrc? I'd like to put in a bunch of > customizations, aliases, etc., but I'm intimidated by the message > saying that my .bashrc will not be updated by setup.exe if I modify > it. Does this mean that I'll have to put in changes for new programs > manually? If so, how can I customize my shell without losing > setup.exe's automation? I'm not familiar with that message from setup, but your .bashrc is yours, to do with as you please. By all means, customize it to create a shell environment to your liking. setup should _never_ mess with your ~/.bashrc. That file belongs to you. Setup may adjust /etc/profile and /etc/bash.bashrc, which provide the system-wide defaults that get executed before your .bashrc. See also the bash man page, "INVOCATION", to see which system and user startup files get executed in what order. Good luck, Andrew. -- 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 2.05 vs. 3.0 Prompt Behavior
>> The 'extra space in the prompt' bug is well known; see e.g. >> http://sources.redhat.com/ml/cygwin/2005-04/msg00325.html and >> http://sourceware.org/ml/cygwin-apps/2005-04/msg00036.html. > > Status update: > The upstream maintainer has been alerted to this issue, and Thomas Dickey has > provided a more detailed evaluation of the problem: > http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00112.html. There is > apparently some interaction between readline and ncurses insert mode, where > readline made some invalid assumptions about invisible characters. And the > code in readline/display.c is HAIRY - Hans' proposed hack that has been > posted > to this list is not a proper fix, just a workaround that hides the worst of > the > bug. > > I'm still working on getting a bash-3.0-8 ready for release (mainly for the > tilde-expansion bug and the missing .info file). If upstream provides a > patch > for the prompt bug in a timely manner, it will be included too. Okay, thanks for working on this. The bug is mildly annoying, but after all mainly cosmetic. -- 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 Win32 environment variables in Cygwin
> Specifically, I need to do > > Set PATH=C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;%PATH% > Set INCLUDE=C:\Program Files\Microsoft Visual C++ Toolkit > 2003\include;%INCLUDE% Set LIB=C:\Program Files\Microsoft Visual Studio > .NET 2003\Vc7\lib;C:\Program Files\Microsoft Visual C++ Toolkit > 2003\lib;%LIB% > > So that VC++ will run properly from the command line. Any suggestions? Since these variables are to be used by a Windows app, it would make most sense to set them in Windows. Then they'll be available to all Windows apps (including others that might start VC++), and also in Cygwin. In XP, you can use the so-well-hidden-it's-almost-gone environment variables pane: right click on my computer, Properties, Advanced, Environment Variables. You may find it easier just to enter them directly into the registry: HKCU\Environment for user-specific variables, or HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment for system-wide variables. For path variables that you want to use in both Windows and Cygwin, there is a path conversion problem, as Igor says. If you're using VC++ and not gcc, then you can just leave INCLUDE et al. as Windows-format paths. But if you want to launch both from Cygwin, then you have a problem, because either path format (Windows or Cygwin) will be wrong for one of them. I guess what's needed is to put the paths into Cygwin format, and write a wrapper script for VC++, that converts them back to Windows format first. Fortunately cygpath(1) can make these conversions for you. Good luck, Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New package: orpie 1.4.1-1
> > The package 'orpie' is now available in the Cygwin distribution. > > There is a packaging bug in this release. > > /etc/default/etc/orpierc > > should be > > /etc/defaults/etc/orpierc Thanks. Sorry, I thought I had corrected this. A new release will come out shortly. > Also I would recommend a postinstall script similar for example to > /etc/postinstall/man.sh.done I included one. Did you not get it? It runs [ -f /etc/orpierc ] || cp /etc/defaults/etc/orpierc /etc -- 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/
who is setting the NAME variable in bash?
I'm running bash 3.0-11. I've just noticed for the first time that the NAME environment variable is set (to the same value as USER). This is breaking one of my Makefiles. Of course I can work around that, but what's bothering me is that I can't figure out why or where NAME is being set. I've grepped for NAME through all of my bash startup files and everything in /etc, and I can't find it. It's not mentioned in the bash man page. Also NAME isn't set on my Linux box at home, which also runs bash 3.0. Any suggestions for how I can figure out who's setting NAME? I want to make them stop. Thanks, Andrew. -- 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: who is setting the NAME variable in bash?
> >Any suggestions for how I can figure out who's setting NAME? I want > >to make them stop. > > Look in your Windows environment. Apparently someone set it for you there. > If you don't want it, you can try removing it. Windows doesn't require it > either so whatever added it is local to your installation So you'll need > to determine the overall validity/usefulness of this variable yourself. Thanks. I forgot to mention it in my first post, but I already checked this. NAME isn't set in the Windows environment, either System or User varieties. However, your suggestion prompted me to look and see which processes have NAME set in their environments. (TaskInfo will show you the environment of every running process.) I found that Explorer.exe has NAME set, and of course all of its descendants do too. That seemed odd, because NAME doesn't appear in Windows' Environment Variables dialog. So I did a little hunting in the registry, and found HKCU\Volatile Environment, which includes the NAME value. I've never encountered HKCU\Volatile Environment before. I believe it's created by the Novell client when I log into our LAN. Anyway, clearing NAME from that key and relogging in solved the problem. Thanks for the suggestion. Andrew. -- 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: gold star request for Andrew Schulman
> I'd like to request a gold star for Andrew Schulman for displaying the > bravery, patience, and organization necessary for maintaining the unison > package. > > This package requires juggling a confusing mishmash of different > versions and, AFAICT, Andrew actually understands it all and is > providing different versions of unison with minimal impact to the cygwin > community. Thanks. Been a while since I got one of them... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server.
> after just a few bytes of network traffic (far > less than the full 400kb), it hangs. Runs of "ps -ef" confirm that the > unison-2.9.20 processes are still running on both machines, but there is > no network traffic, and no CPU usage. > > Attempts to run Unison on directories with lots of changed files, such > that Unison has multiple connections running, crash at the same point > with uncaught exceptions or "broken pipe" errors instead of hanging. (I > can reproduce those if they'd be useful, but they seemed just random and > cryptic, and they weren't consistent if I changed the files, so I didn't > save them.) Brooks, I do remember seeing a lot of reports about 6 months or so ago, that Unison was hanging. My recollection is dim but I think it had to do with some bad combination of versions of cygwin.dll and Unison. Are you using the latest cygwin.dll on your servers? Invoking unison with -debug will provide a lot of output, which may or may not be useful. At least you can see what was the last thing Unison was doing before it hung, and that may ring a bell somewhere. Also, exceptions and broken pipes are obvious errors that may lead more easily to a solution if you report the details. On balance though, I recommend that you upgrade to a recent (or at least more recent) version of Unison if you can. 2.9.20 is getting pretty old now. It's still provided in Cygwin in order to allow maximum version compatibility with other hosts, but there are a ton of bug fixes and many new features in later versions. Several more recent versions of Unison are available in Cygwin. On FreeBSD I don't know, but even if you have to fetch and build a more recent version yourself, this is usually easy as long as you have OCaml installed. Of course all of your hosts have to be running the same version of Unison, since different versions won't talk to each other; or with versions 2.13.x and later, only the first two version numbers (e.g. 2.13) have to match. Good luck, Andrew. -- 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: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server.
> > Brooks, I do remember seeing a lot of reports about 6 months or so > > ago, that Unison was hanging. My recollection is dim but I think it > > had to do with some bad combination of versions of cygwin.dll and > > Unison. Are you using the latest cygwin.dll on your servers? > > "uname -sr" returns "CYGWIN_NT-5.2 1.5.18(0.132/4/2)", which I believe > means I'm running the latest version. > > I also noticed that there was a new OpenSSH package out; I've upgraded > to OpenSSH-4.2p1-1 on the server side, and found that this changed > nothing with regards to this bug. OK. > > Invoking unison with -debug will provide a lot of output, which may or > > may not be useful. At least you can see what was the last thing > > Unison was doing before it hung, and that may ring a bell somewhere. > > Also, exceptions and broken pipes are obvious errors that may lead > > more easily to a solution if you report the details. > > True enough. I've attached the text of unison -debug 'all' to this; I'm > not sure if it's meaningful or not. No, probably not. At least not to me... it just looks like the typical Unison hang: everything seems to be going along fine, and then it just stops. > > Uncaught exception File > > "/home/aschulma/usr/cygwin/unison2.9.20/unison2.9.20-2.9.20/.build/remote.ml > > ", line 483, characters 2-8: Assertion failed > > Broken pipe > > Incidentally, this points out a definite bug in Unison-2.9.20. This > exact output also occurs if I specify "-maxthreads 1" on the command > line, indicating that it is ignoring that option and opening the default > 20 threads anyway. (If I use the "-debug 'all'" option along with > "-maxthreads 1", it does report "maxthreads = 1" in the list at the > beginning, so it's parsing the option, just ignoring it.) I suggest that you report both of these errors to the unison-users list: http://groups.yahoo.com/group/unison-users. The Unison developers are generally pretty good about fixing failed assertions, which shouldn't ever happen. They may ask you for more information and/or testing and then post a patch, in which case I'll immediately incorporate it into the Cygwin package and release a new version. However, they may also decline to keep supporting version 2.9.20-- I don't know. If they do, then that suggests that it may be time to remove 2.9.20 (and also 2.9.1) from Cygwin, too. We'll see. > Unfortunately, I don't have root on the remote server, so it may be a > little difficult to upgrade, but I see that Cygwin does seem to allow > having multiple versions of unison around -- many thanks to whomever was > responsible for that! You're welcome :) As for being root on your server, that's not required. You can build and install a private copy of Unison (whatever version you like), then from your client just run unison with -serverCmd /path/to/your/local/unison. Good luck, A. -- 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/
cygblas.dll not found (lapack)
I'm trying to run orpie in Cygwin. When I start it, a window pops up saying "cygblas.dll not found". orpie requires gsl, which requires lapack, which includes /usr/lib/lapack/cygblas.dll. All of these packages are installed on my host, and I do have /usr/lib/lapack/cygblas.dll. The problem seems to be that /usr/lib/lapack isn't in my PATH, and cygblas.dll is only found there. So it seems to me that either (1) lapack expects me to permanently add /usr/lib/lapack to my PATH, or (2) lapack makes some other provision for finding cygblas.dll, but it isn't working for me. In Linux I would tweak /etc/ld.so.conf and then run ldconfig. But these don't exist in Cygwin (at least on my host). I could live with #1 above, but I wouldn't like it. It doesn't seem right-- my PATH would get very long if I had to do this for every package. I could also just copy cygblas.dll into /usr/bin, but again I shouldn't have to do this. Can someone suggest what the trouble is, or what's the right way to find cygblas.dll? Thanks, Andrew. -- 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: cygblas.dll not found (lapack)
> >(2) lapack makes some other provision for finding cygblas.dll, but it > >isn't working for me. > > This is the right choice. lapack installs /etc/profile.d/lapack.sh, which > does > what you want; putting /usr/lib/lapack in your path. > > The default /etc/profile executes all scripts in /etc/profile.d when you log > in. You may need to log out and log back in if your shell was started before > lapack was installed. > > Another possibility is that you are blowing away the default path in your own > .profile, and installing your own - please check on that. Thanks. Yes, I do explicitly set my own PATH in my .bashrc. I guess I'll just add /usr/lib/lapack to it. Is there some reason that lapack can't put cygblas.dll into /usr/bin instead of /usr/lib/lapack? I realize that that probably doesn't agree with the Linux FHS, but it does seem to be standard practice in Cygwin-- I have 116 files named /usr/bin/cyg*.dll on my host. Thanks, Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New packages: ploticus, libploticus, ploticus-common, ploticus-doc
Ploticus is now available in the Cygwin distribution. Ploticus is command-line software for creating plots, charts, and graphics from data. Ploticus is good for automated or just-in-time graph generation. With ploticus you can use 'prefabs' to quickly create common types of graphs, or write scripts to get full control. Ploticus can make scatter, bar, box, range, vector, pie, and venn charts, and offers curve fitting, multiple axes and plot areas, legends, and text overlays. It allows significant user control over colors, styles, options and details. It handles date and time data nicely, and has basic statistical capabilities. The results can be output to an X11 display or as PNG, JPEG, WBMP, SVG, PS, or EPS images. Ploticus can also generate image maps and mouseover labels, for inclusion into Web pages. Ploticus is divided into four packages in Cygwin: ploticus: Ploticus executable and test suite. Please note that although the ploticus manual refers to the ploticus executable as 'pl', in Cygwin its name is /usr/bin/ploticus. (The name /usr/bin/pl is already taken by a file in the SWI-Prolog package.) You must either substitute 'ploticus' in place of 'pl' everywhere, or else create a symlink, e.g. from /usr/local/bin/pl to /usr/bin/ploticus. This should work just fine as long as you don't have the SWI-Prolog package installed. libploticus: Static library of ploticus functions, for inclusion into C programs. See http://ploticus.sourceforge.net/doc/api.html for documentation of the libploticus API. ploticus-common: Prefabs. ploticus and libploticus both depend on this package, so you shouldn't have to explicitly select it for installation. ploticus-doc: HTML documentation, gallery, and examples. If you don't mind going online to read the ploticus documentation, then you don't need to install this package. Source homepage:http://ploticus.sourceforge.net/ License:GPL Please address questions and bug reports to the Cygwin mailing list . Andrew E. Schulman *** To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. *** -- 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/
popularity-contest for Cygwin?
Debian has a package called popularity-contest: http://packages.debian.org/stable/misc/popularity-contest. The package installs a cron job that mails in statistics once a week about which Debian packages the user has installed, and which ones they're using. This allows the Debian team to track which packages (and versions) are most often used. Of course this is entirely a self-selected sample, since no user is required to install the package. But that doesn't seem to introduce any bias. popularity-contest seems like a useful tool, and I wish there were a similar one for Cygwin. Of course it requires server support, which could be a large project. I'm not suggesting we try to implement it-- I certainly don't have the time. But maybe there's some simpler approach. I maintain 14 packages for Cygwin. Some of them need almost no maintenance, but others need fairly frequent updates. I don't mind, but I do sometimes wonder whether anyone is using some of them. As things stand now, I have no way of knowing, except by following the mailing lists, if even one person has installed or is using some of my packages (lablgtk2? orpie? stow?). A popularity-contest-like tool would help all of us Cygwin packagers to focus our efforts on the tools that are most useful to users. Anyone have any thoughts about how to implement such a tool? Volunteers to take it on? :) Andrew. -- 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: Good bye, Cygwinners
> Hi all. > > I am no longer working with Windows, so I have no free resources (including > time) to maintain my Cygwin packages. The list (I hope that it is complete) of > my packages follows: > > docbook-xml412 > docbook-xml42 > docbook-xml43 > docbook-xml44 > docbook-xsl > hexedit > ioperm > stunnel > xmlto Aak! I use stunnel daily. I don't think Cygwin can afford to lose it as a package. I've looked at it and it doesn't look as though it will pose any packaging problems. I'll see if I can build it in the next few days and if so take it over. I might also take over hexedit, but that is lower priority. -- 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: mssing packages for cygwin
> I find that I miss the command such as size.exe ar.exe, nm.exe, > make.exe, awk.exe and strip.exe etc > where can I find those packages to insall? are there any instructions I > need to follow for installation? Please Read the Fine 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: I would like a post deleted
> Ironically enough, by reposting the message, there are now two copies of it > in the archives. > > I think Bobby may have inadvertently quoted it as well. > > Oops. > > I see it's available on nabble and gmane as well. And mail-archive.org, and > MARC. Amd who knows how many other list archives... Perhaps he could now send a new copy of the message to the support mailing lists of each of those archives, asking that their copies be expunged... the mathematics of it are amusing. Live and learn. Andrew. -- 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: stupid spaces in environment vars
> BAD:
> alias cdp=cd\ "$USERPROFILE"
> +alias 'cdp=cd C:\Documents and Settings\me'
>
> alias cdp="cd $USERPROFILE"
> +alias 'cdp=cd C:\Documents and Settings\me'
>
> GOOD:
> alias cdp="cd \"$USERPROFILE\""
> + alias 'cdp=cd "C:\Documents and Settings\me"'
>
> alias cdp='cd "$USERPROFILE"'
> + alias 'cdp=cd "$USERPROFILE"'
To avoid one layer of quoting, how about
function cdp () { cd "$USERPROFILE"; }
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated:lftp-3.5.9-1
> > lftp ftp.microsoft.com > lftp: host name resolve timeout I'm not able to reproduce this problem: $ lftp ftp.microsoft.com lftp ftp.microsoft.com:~> ls dr-xr-xr-x 1 ownergroup 0 Jan 25 11:03 bussys dr-xr-xr-x 1 ownergroup 0 Jan 25 11:18 deskapps dr-xr-xr-x 1 ownergroup 0 Jan 25 11:22 developr dr-xr-xr-x 1 ownergroup 0 Jan 25 11:22 KBHelp dr-xr-xr-x 1 ownergroup 0 Jan 25 11:38 MISC dr-xr-xr-x 1 ownergroup 0 Jan 25 11:43 MISC1 dr-xr-xr-x 1 ownergroup 0 Jan 25 11:45 peropsys dr-xr-xr-x 1 ownergroup 0 Jan 25 11:52 Products dr-xr-xr-x 1 ownergroup 0 Jan 25 11:52 PSS dr-xr-xr-x 1 ownergroup 0 Jan 25 11:53 ResKit dr-xr-xr-x 1 ownergroup 0 Jan 25 12:11 Services dr-xr-xr-x 1 ownergroup 0 Jan 25 17:38 Softlib lftp ftp.microsoft.com:/> exit $ lftp --version LFTP | Version 3.5.9 | Copyright (c) 1996-2006 Alexander V. Lukyanov Libraries used: Readline 5.2, Expat 1.95.8, OpenSSL 0.9.8d 28 Sep 2006, libiconv 1.11 --- I'm glad to help troubleshoot, but I probably can't do much until or unless I can observe the problem. Please attach output of cygcheck -svr. Does 'nslookup ftp.microsoft.com' work for you? Andrew. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated:lftp-3.5.9-1
> * Andrew Schulman (Mon, 12 Feb 2007 10:12:54 -0500) > > > > lftp ftp.microsoft.com > > > lftp: host name resolve timeout > > > > I'm not able to reproduce this problem: > > I figured it out myself: it's the "dns:fatal-timeout 0" setting in my > .lftprc. The funny thing is that "0" is the default and actually means > "no timeout" > > man lftp > "dns:fatal-timeout (seconds) > limit the time for DNS queries. If DNS server is unavailable too long, > lftp will fail to resolve a given host name. 0 means > unlimited, the default." > > It's a classical bug, my Linux lftp 3.5.7 shows the same behaviour. OK, I'm glad you found it. A few comments: (1) The man page for version 3.5.9 says something different from what you show above: dns:fatal-timeout (time interval) limit the time for DNS queries. If DNS server is unavailable too long, lftp will fail to resolve a given host name. Set to `never' to disable. So setting it to 0 should probably be expected to be fatal. Maybe this is what changed in version 3.4.4, that caused your setup to stop working with Cygwin then. On my host without setting dns:fatal-timeout, its value is 7d. (2) lftp is fairly complex and I'm still learning it. For future bug reports I'll ask users to attach their .lftprc files and look first in the settings, of which there are about 200. Good luck, Andrew. -- 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/
