cygwin.cygwin.narkive.com
Hi , We work with businesses to provide a stable cloud based phone solution with video conferencing and text messaging at a reduced rate from your traditional telephone provider. Its levels beyond what other platforms offer, with features like call recording, call ID, tracking, linking to a CRM, etc. May I send some information to you about our VOIP service? Best regards, Glenn Bogdan | TeleSpecialist *24X7 OnTop LLC* 5859 McDovie Ave, Woodland Hills, CA 91367 Other Presence: MA | WA | CO | ID | DE | CT | UT | GA and FL If you want to put an end to our email, please reply with RULE-OUT. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re :Delivery/E-commerce App/web free demo
Good day. , Are you looking any kind of ready-made on-demand Web-Apps Solution like (B2B2C) Model, So don't wait for book free demo. Ready to go-live delivery Website-Mobile Apps Solution for Categories We Serve: Food, Pizza, Restaurant, Groceries, Courier, Flowers and Gifts, Laundry, Healthcare products, Home appliance services delivery, Lifestyle product delivery including Taxi/Cab booking. Transportation & logistics Dating Apps and many more... Let us know what readymade Web-Apps Solution, you're looking on and we'd be happy to set up a free demo consultative first meeting, with no pressure to sign. Thanks, -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Failure of the inetutils-server.sh postinstall script
Hi, I installed the inetutils package but not inetutils-server. The installer then executed the inetutils-server.sh. The script then failed because the getent package, which I presume is a prerequisite for inetutils-server but not inetutils, had not been installed. I hope this information is useful to you. Cheers, Bogdan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
64-bit coreutils missing hostname utility
Hi, The 64-bit port of the coreutils package is missing the hostname utility. Cheers, Bogdan
Re: [ITP] asa 1.1
Base is definitely not the right category. Conversion for output by Fortran programs seems like a pretty small target audience. This doesn't seem to be available in at least two popular linux distributions so you'll need to get votes. While I agree that it's of limited value, I thought the fact that it's defined by POSIX might be of some relevance. At this point, I probably should not say that I was also going to offer to package SCCS. :) Cheers, Bogdan
[ITP] asa 1.1
Hi, Unless anyone else wants to, I volunteer to package and maintain an implementation of the POSIX asa utility. The implementation I have in mind was written by Thomas Koenig and its home is mentioned in the setup.hint file, below. It is a Fortran runtime utility that interprets carriage-control characters. setup.hint: # This utility comes from ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran sdesc: ASA Carriage control conversion for output by Fortran programs category: Base I don't know whether Base is the right category but it's pretty similar to what dos2unix does, the latter being part of Base. Cheers, Bogdan
64-bit Cygwin - Missing packages and mintty issue
Hi, I've just installed the 64-bit Cygwin port but encountered a few problems. First of all, there seems to be a problem with the mintty package. While it's marked as installed in the setup, /bin/mintty does not exist so I cannot fire up the terminal. I suspect the package has not been installed. Secondly, at least the following packages are missing (they don't even show up in the setup's database): inetutils, pax, time, and (according to someone else, I haven't checked) lftp. I suspect others are missing as well. Cheers, Bogdan
Expect script works in 1.5 but fails in 1.7
Hi, I have a simple Expect script that starts as: set timeout -1 spawn ftp a.b.c.d match_max 10 expect *Name (a.b.c.d): send -- anonymous\r expect *Password: send -- anonymous\r This is fine in Cygwin 1.5 on my PC (installed in Nov 2008) yet on some other PCs where I installed, last week, Cygwin 1.7 it fails at the Password introduction. I tried more combinations of stty echo and/or raw but without success. Either it hangs without prompting the Password: or it prompts and gets the first character but the rest of chars are echoed on a new line and the login fails. Thank you very much! Bogdan Nicolau PS A short sample of my setup-for working PC- is here: bash: cd: [~]$: No such file or directory [~]$ cd C:\backup\LaptopTools\ExpectWinUnix\expect-5.44.1\example [/cygdrive/c/backup/LaptopTools/ExpectWinUnix/expect-5.44.1/example]$ strace ftp a.b.c.d ** Program name: C:\cygwin\bin\ftp.exe (pid 30700, ppid 1) App version: 1007.0, api: 0.167 DLL version: 1005.25, api: 0.156 DLL build: 2008-06-12 19:34 OS version: Windows NT-6.0 Heap size: 402653184 Date/Time: 2010-02-15 12:30:59 ** 32 3949 [main] ftp 30700 set_myself: myself-dwProcessId 30700 32 3981 [main] ftp 30700 time: 1266265859 = time (0) 467 4448 [main] ftp 30700 environ_init: GetEnvironmentStrings returned 0x628138 - =C:=C:\cygwin\bin 57 4505 [main] ftp 30700 environ_init: 0x10A0238: !C:=C:\cygwin\bin 56 4561 [main] ftp 30700 environ_init: 0x10A0250: ALLUSERSPROFILE=C:\ProgramData 64 4625 [main] ftp 30700 environ_init: 0x10A0278: APPDATA=C:\Users\lmcabcd\AppData\Roaming 85 4710 [main] ftp 30700 environ_init: 0x10A02A8: COLORFGBG=15;default;0 73 4783 [main] ftp 30700 environ_init: 0x10A02C8: COLORTERM=rxvt-xpm 51 4834 [main] ftp 30700 environ_init: 0x10A02E0: COMMONPROGRAMFILES=C:\Program Files\Common Files 76 4910 [main] ftp 30700 environ_init: 0x10A0318: COMPUTERNAME=EV001F2990CA02 52 4962 [main] ftp 30700 environ_init: 0x10A0338: COMSPEC=C:\Windows\system32\cmd.exe 50 5012 [main] ftp 30700 environ_init: 0x10A0360: DISPLAY=:0 49 5061 [main] ftp 30700 environ_init: 0x10A0370: FP_NO_HOST_CHECK=NO 61 5122 [main] ftp 30700 getwinenv: can't set native for HOME= since no environ yet ... a similar strace for the non-working PC is here: $ strace expect -f autoexpect ftp a.b.c.d ** Program name: E:\cygwin\bin\expect.exe (pid 3248, ppid 1) App version: 1003.15, api: 0.63 DLL version: 1005.25, api: 0.156 wait_sig: entering ReadFile loop, my_readsig 0x0, my_sendsig 0x0 DLL build: 2008-06-12 19:34 OS version: Windows NT-5.1 Heap size: 402653184 Date/Time: 2010-02-15 12:05:11 ** 199 1525 [main] expect 3248 set_myself: myself-dwProcessId 3248 150 1675 [main] expect 3248 time: 1266264311 = time (0) 761 2436 [main] expect 3248 environ_init: GetEnvironmentStrings returned 0x245300 - =::=::\ 264 2700 [main] expect 3248 environ_init: 0x700238: !::=::\ 216 2916 [main] expect 3248 environ_init: 0x700248: !E:=E:\cygwin\bin 177 3093 [main] expect 3248 environ_init: 0x700260: ALLUSERSPROFILE=E:\Documents and Settings\A 247 3340 [main] expect 3248 environ_init: 0x700298: APPDATA=E:\Documents and Settings\Abcd a 332 3672 [main] expect 3248 environ_init: 0x7002E0: CLIENTNAME=Console 215 3887 [main] expect 3248 environ_init: 0x7002F8: COMMONPROGRAMFILES=E:\Program Files\Common 244 4131 [main] expect 3248 environ_init: 0x700330: COMPUTERNAME=ABCD-281CCA 238 4369 [main] expect 3248 environ_init: 0x700358: COMSPEC=E:\WINDOWS\system32\cmd.exe 252 4621 [main] expect 3248 environ_init: 0x700380: CVS_RSH=/bin/ssh 229 4850 [main] expect 3248 environ_init: 0x700398: FP_NO_HOST_CHECK=NO 236 5086 [main] expect 3248 getwinenv: can't set native for HOME= since no environ yet ... User (carroll.aset.psu.edu:(none)): 1820 6243445 [main] expect 3248 fhandler_console::write: 36 = w 3396 6246841 [main] expect 3248 cygwin_select: 6, 0x701B6C, 0x701B74, 0x701B7C, 0x0 1701 6248542 [main] expect 3248 dtable::select_read: /dev/console fd 0 1520 6250062 [main] expect 3248 dtable::select_except: /dev/console fd 0 1706 6251768 [main] expect 3248 dtable::select_read: /dev/ptmx fd 5 1615 6253383 [main] expect 3248 dtable::select_except: /dev/ptmx fd 5 1681 6255064 [main] expect 3248 cygwin_select: to NULL, ms 1725 6256789 [main] expect 3248 cygwin_select: sel.always_ready 0 1856 6258645 [main] expect 3248 select_stuff::wait: m 3, ms 4294967295 13735553 19994198 [main] expect 3248 select_stuff::wait: woke up. wait_ret 2. verifying 247 19994445 [main] expect 3248 select_stuff::wait: gotone 1 185 19994630 [main] expect 3248
possible cygwin_select problem: rtorrent freezes under cygwin 1.7
Hi, I've compiled and installed a console torrent client rTorrent 0.8.5 under cygwin, following instructions here: http://rtwi.jmk.hu/wiki/rTorrentOnWindows The problem is that rTorrent freezes for random-length periods of time with 100% CPU use. That same version of rTorrent does not freeze on that same computer on Debian GNU/Linux. I have posted more details (including strace and gdb debugging attempts) here: http://libtorrent.rakshasa.no/ticket/1163#comment:7 It appears that FreeBSD 6.x might have a similar problem, if that is relevant. I will be glad to provide more information. Regards, Bogdan freemail appends ads, sorry: -- реклама --- Товары от 1 грн! Теперь все покупают на Aukro.ua! Всегда новые интересные покупки на интернет-аукционе http://aukro.ua -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Running cygwin on multiple computers from a shared network drive
I want to keep a cygwin installation on a shared network drive and then then use it from any computer. Has anybody accomplished this? Can you point me to some instructions? I would guess there is some setup required, such as loading the mount points in registry. Anything else? Thanks 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/
1.5.11: resuming a suspended sleep results in undelivered signal 19
Greetings, Pierre Humblet discovered this and since I had a trace of it, encouraged me to post it. A suspended sleep call is resumed, but does not exit at the expiration time. $ sleep 20 ^Z [1]+ Stopped sleep 20 $ fg sleep 20 ...forever... In a separate shell, the sleep is straced after it is started but before the ^Z is performed. (see also attached) snip 146 16802759 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 70 16802829 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 83 16802912 [sig] sleep 4236 setup_handler: signal 19 not delivered 69 16802981 [sig] sleep 4236 sigpacket::process: returning 0 snip Curious. Possible tie-in with this thread: http://sources.redhat.com/ml/cygwin/2004-09/msg00818.html Best Regards, -bogdan 13 13 [unknown (0x72C)] sleep 4236 _cygtls::remove: wait 0x0 235 248 [unknown (0x72C)] sleep 4236 _cygtls::remove: removed 0xD1F140 element 1 5737716 5737964 [sig] sleep 4236 sigpacket::process: signal 18 processing 206 5738170 [sig] sleep 4236 _cygtls::find_tls: sig 18 211 5738381 [sig] sleep 4236 sigpacket::process: signal 18, about to call 0x61014D20 93 5738474 [sig] sleep 4236 setup_handler: controlled interrupt. incyg 1, exception 0, stackptr 0x22FC04, stack 0x22FC00, stackptr[-1] 0x402992 95 5738569 [sig] sleep 4236 proc_subproc: args: 3, 1 87 5738656 [sig] sleep 4236 proc_subproc: clear waiting threads 88 5738744 [sig] sleep 4236 proc_subproc: finished clearing 85 5738829 [sig] sleep 4236 proc_subproc: returning 1 276 5739105 [sig] sleep 4236 _cygtls::interrupt_setup: armed signal_arrived 0x344, sig 18, res 1 93 5739198 [sig] sleep 4236 setup_handler: signal 18 delivered 91 5739289 [sig] sleep 4236 sigpacket::process: returning 1 100 5739389 [main] sleep 4236 cygwin_select: signal received 89 5739478 [main] sleep 4236 select_stuff::cleanup: calling cleanup routines 78 5739556 [main] sleep 4236 select_stuff::~select_stuff: deleting select records 80 5739636 [main] sleep 4236 set_process_mask_delta: oldmask 0x0, newmask 0x2, deltamask 0x2 80 5739716 [main] sleep 4236 reset_signal_arrived: reset signal_arrived 79 5739795 [main] sleep 4236 reset_signal_arrived: stackptr[-1] 0x402992 140 5739935 [main] sleep 4236 sig_send: sendsig 0x2AC, pid 4000, signal 20, its_me 0 492 5740427 [main] sleep 4236 sig_send: Not waiting for sigcomplete. its_me 0 signal 20 118 5740545 [main] sleep 4236 sig_send: returning 0x0 from sending signal 20 92 5740637 [main] sleep 4236 sig_handle_tty_stop: process 4236 stopped by signal 18, myself-ppid_handle 0x3F4 11056255 16796892 [sig] sleep 4236 sigpacket::process: signal 19 processing 165 16797057 [sig] sleep 4236 _cygtls::find_tls: sig 19 83 16797140 [sig] sleep 4236 sigpacket::process: signal 19, about to call 0x402930 78 16797218 [sig] sleep 4236 setup_handler: suspending mainthread 128 16797346 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 79 16797425 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 103 16797528 [sig] sleep 4236 setup_handler: suspending mainthread 104 16797632 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 75 16797707 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 87 16797794 [sig] sleep 4236 setup_handler: suspending mainthread 108 16797902 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 72 16797974 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 91 16798065 [sig] sleep 4236 setup_handler: suspending mainthread 103 16798168 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 75 16798243 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 87 16798330 [sig] sleep 4236 setup_handler: suspending mainthread 115 16798445 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 70 16798515 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 90 16798605 [sig] sleep 4236 setup_handler: suspending mainthread 102 16798707 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 74 16798781 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 86 16798867 [sig] sleep 4236 setup_handler: suspending mainthread 109 16798976 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 71 16799047 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 89 16799136 [sig] sleep 4236 setup_handler: suspending mainthread 102 16799238 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8, interruptible 0 74 16799312 [sig] sleep 4236 setup_handler: couldn't interrupt. trying again. 90 16799402 [sig] sleep 4236 setup_handler: suspending mainthread 258 16799660 [sig] sleep 4236 interruptible: pc 0x77F8287E, h 0x77F8
RE: 1.5.11: resuming a suspended sleep results in undelivered signal 19
It is actually more likely a tie in with: http://sources.redhat.com/ml/cygwin/2004-09/msg00315.html Yah! Light years away... :) This problem should be fixed in the latest snapshot. Indeed, it is. Many thanks! -bogdan -- 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.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, My local tests and all reports from rtems-users so far are successes. -bogdan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ekberg Sent: Wednesday, September 15, 2004 3:24 AM To: [EMAIL PROTECTED] Subject: RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1) Christopher Faylor wrote: Grr... This was the newlib problem previously mentioned. I forgot to generate the snapshot in such a way as to work around this problem. The new snapshot should work better. Indeed it does. I have tried a couple of times without any hickups. With 1.5.11 a have not been able to get my testcase to even pass once if straceing. With this snapshot I now have 5 consecutive successes (and no failures). I'm afraid I don't understand the issue and why the temporary change in the snapshot points at bash, so someone else is probably better suited to notify the bash maintainer. (If the evidence in this message qualifies as confirmation.) BTW, thanks for helping out with debugging! Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, Pierre, I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. In my failure cases, configure is run under bash. I have also captured (finally?) an strace under the ~current cygwin (attached). The details are largely the same as Peter's last attachment, to which Igor remarked FWIW, expr.exe does seem to exit with the right exit code, but is later zombified, which doesn't sound quite right. Actually, its ok for it to be zombified, because the parent didn't happen to be waiting for the child at the time that the child exited. Pierre's observation that error text is output by the parent shell *before* the expr command even executes was an inspiration. So it seems like the parent shell decides its going to exit after forking but before waiting on the expr process. This is consistent across all my straces as well as Peter's. In my attached trace, this is between lines 582 and 750; I also noticed the following: 84 16461744 [main] bash 1048 close: close (1) 1378 16461829 [main] bash 2028 close: close (1) On line 725 and 726. By the time my trace got to line 750, the parent shell had stated to output the error text (53 characters in my case). I have another trace that exhibits this too. Peter's trace does not have this. In my trace (not Peter's) there are also some lines like: 324 16458452 [main] bash 1048 fhandler_base::set_no_inheritance: DuplicateHandle failed, The parameter is incorrect. 237 16458689 [main] bash 1048 fhandler_base::set_close_on_exec: set close_on_exec for /dev/console to 1 In the time between the fork and the beginning of the error write, but this is not unique to the trace and it was handled apparently ok previously in the script. Wasn't there a registry value that controlled how pids were allocated? I can't find anything appropriate in google. I looked for something about this in M$ knowledge base. I didn't find that, but I found this: BUG: Registry access from multiple threads might fail (WinNT, Win2K) http://support.microsoft.com/default.aspx?scid=kb;en-us;176906 -bogdan -- 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.10: expr + configure failure + testcase (also on 1.5.11-1)
Hi Peter, Yes, the new trace is with cygwin1.dll 1.5.11-1, the old one was with 1.5.10-3, sorry if I didn't mention that... No, that's fine. It would have been significant if you *had not* upgraded and yet produced that failure. -bogdan -- 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.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. Thanks! -bogdan -- 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.10: expr + configure failure + testcase (also on 1.5.11-1)
Pierre,
FYI, I lauched that script last evening, it's now at
iteration 6441. That's on NT4 with a 2 day old cygwin dll
built from cvs.
I have seen all the latest e-mails in this thread and the plea
to use the new snapshot.
So you are not using the new snapshot, yet do not see the failure, correct?
Chris Johns on the RTEMS list reported that my configure line did not fail on his
MinGW system as readily as his configure line; his
line fails just as well on my system, so we've adopted it as the default now.
Please replace the fail() with the following in test-configure:
fail () {
${configure_test} -n \
--prefix=/opt/rtems \
--with-multisubdir=m68000 \
--with-multisrctop= \
--with-multibuildtop= \
--prefix=/opt/rtems \
--host=m68k-rtems \
--build=i686-pc-mingw32 \
--target=m68k-rtems \
--enable-multilib \
--enable-doc \
--enable-cxx \
--enable-posix \
--enable-networking \
--disable-tests \
--disable-itron \
--with-target-subdir=m68k-rtems \
--exec-prefix=/opt/rtems/m68k-rtems \
--cache-file=/dev/null \
build_alias=i686-pc-mingw32 \
host_alias=m68k-rtems \
target_alias=m68k-rtems \
CC='m68k-rtems-gcc --pipe -m68000' \
--cache-file=/dev/null
}
and make another run, hopefully *before* you install the snapshot.
So far on the rtems-list, reports of the configure problem have implicated Win98/WinME
and Win2K. No failure was reported
MinGW/WinXP. I'm still waiting to hear from others.
By the way, I never got a chance to respond to your request for a simpler test case.
Believe me, I tried. The exhaustive/iterative
method was the best I could do to come close to quickly returning a failure if the
problem existed. On my system, I'd have a better
than 1:2 chance of getting a failure, but other people reported different results.
It would *never* fail, if all you did was a few expr and tests. The whole configure
script machinery appears necessary to setup the
failure mode.
Thanks,
-bogdan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre A. Humblet
Sent: Tuesday, September 14, 2004 10:04 AM
To: [EMAIL PROTECTED]
Subject: Re: 1.5.10: expr + configure failure + testcase
(also on 1.5.11-1)
On Sun, Sep 12, 2004 at 09:42:07PM -0400, Bogdan Vacaliuc wrote:
Anyway, the attached script (test-configure) will create the above
configure.ac, generate configure (via. autoconf), and run the above
line over and over until failure. I am also attaching cygcheck.out
for my environment as it now exists.
FYI, I lauched that script last evening, it's now at
iteration 6441. That's on NT4 with a 2 day old cygwin dll
built from cvs.
I have seen all the latest e-mails in this thread and the plea
to use the new snapshot.
BTW, checking for reused PIDs is a trace is very easy:
fgrep Program the_trace
Pierre
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: HELP: How to disable killing of Bash Shell window with mouse?
Hi Pekka, http://www.google.com/search?hl=enlr=ie=UTF-8q=%2Bdisable+%2Bclose+%2Bwindow The first hit is: http://www.handyarchive.com/Desktop/Shell-Enhancements/4-WinTopMost-Site-License.html Which is a link to a commercial product, but perhaps it will satisfy you or perhaps more searching will give the answer you seek. Best Regards, -bogdan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Niiranen Sent: Monday, September 13, 2004 12:20 PM To: [EMAIL PROTECTED] Subject: HELP: How to disable killing of Bash Shell window with mouse? Hi there, Killing Cygwin Shell Window with mouse leaves bash.exe running. which can be seen from W2K task manager. How can I disable X -button from the Shell Windows so that the user is forced to TYPE exit on command prompt? Recompiling? -pekka- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Hello again, After (finally?!) noticing that a new release of the cygwin.dll was made on Sept. 4 and being encouraged by the line: - Fix mysterious configure script premature exit. (Pierre Humblet) I decided to check against the latest public release. The problem continues to persist, unfortunately. I created a simplified testcase, by realizing that a simple configure.ac will let autoconf generate a suitable configure script. This auto-generated configure script exhibits the argument parsing failure as readily as any script taken from a build environment. It is also attached (as text this time, sorry for all the compressed business I mucked with previously). Here is the configure.ac file needed for autoconf: [/jail/cygwin-1.5.11.1-std] cat configure.ac AC_PREREQ(2.57) AC_INIT([expr-configure],[1.5.11-1],[cygwin at cygwin dot com]) # for the purpose of this test, getting here is a success exit 0 To generate the configure script, just run 'autoconf'. The command for configure that exhibits the failure is: ./configure -n \ --target=i386-rtems \ --enable-rtemsbsp=386pc \ --host=i686-pc-cygwin \ --build=i686-pc-cygwin \ build_alias=i686-pc-cygwin \ host_alias=i686-pc-cygwin \ target_alias=i386-rtems \ --cache-file=/dev/null It doesn't happen all the time, of course. The *extremely curious* thing is that simply removing the '--enable-rtemsbsp=386pc' appears to make the configure script work all the time. I have experimented with reordering the arguments, putting '--cache-file=/dev/null' at the top, etc. It is easy to make the problem go away. This sequence seems to cause the problem most quickly. While performing the above tests in my chroot jails, I observed a new failure mode: [/jail/cygwin-1.5.11.1-std] ./test-configure *** CREATE configure.ac *** *** GENERATE configure *** Running using function fail()... *** TEST 0 *** *** TEST 1 *** *** TEST 1 FAILS *** configure: error: invalid variable name: build_alias [/jail] chroot /jail/cygwin-1.5.11.1-std /bin/bash -l $ ./test-configure Running using function fail()... *** TEST 0 *** *** TEST 0 FAILS *** configure: error: sources are in /, but `cd /' does not work This does not occur, if I replace /bin/bash in the jail with a locally compiled bash.exe (based on 2.05b, that has the RECYCLES_PIDS defined): [/jail] chroot /jail/cygwin-1.5.11.1-bash205b /bin/bash -l $ ./test-configure Running using function fail()... *** TEST 0 *** *** TEST 1 *** *** TEST 2 *** *** TEST 3 *** *** TEST 4 *** *** TEST 5 *** *** TEST 6 *** *** TEST 7 *** *** TEST 8 *** *** TEST 8 FAILS *** configure: error: invalid variable name: build_alias Rather, the issue we are pursuing occurs. What is interesting, is that in the 'std' case above, if one keeps calling the script, one can get the 'invalid variable name' error *instead* of the 'sources are in...' error. This suggests that the two are possibly related and 'RECYCLES_PIDS' has some bearing on the real issue. Anyway, the attached script (test-configure) will create the above configure.ac, generate configure (via. autoconf), and run the above line over and over until failure. I am also attaching cygcheck.out for my environment as it now exists. Thanks to anyone looking at this; even if simply to say 'yup, it's a problem', or 'no, you are wrong about this...' Best Regards, -bogdan p.s. For a chroot jail, the following programs are required at a minimum: $ ls /bin bash.execygintl-2.dll cygpcreposix.dll ls.exe sleep.exe cat.exe cygintl-3.dll cygwin1.dll mkdir.exe sort.exe chmod.exe cygintl.dll date.exe pwd.exetail.exe clear.exe cygpcre-0.dll echo.exe rm.exe touch.exe cygiconv-2.dll cygpcre.dll expr.exe sed.exewc.exe cygintl-1.dll cygpcreposix-0.dll grep.exe sh.exe $ ls /etc profile $ cat /etc/profile PATH=/bin PS1='$ ' p.p.s. Refer to my original post for any required background: http://www.cygwin.com/ml/cygwin/2004-09/msg00518.html test-configure Description: Binary data cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.10: expr + configure failure + testcase
Greetings, The RTEMS project has also experienced the configure/expr problem over the last few weeks. A number of people have been working on it, and I would like to present our findings as well as offer a test case that exposes the problem fairly readily. As Igor has deduced in (http://sources.redhat.com/ml/cygwin/2004-08/msg01339.html), the failure mode is an incorrect interpretation of the exit status from invocations of 'expr' in configure.test. The actual call to 'expr' produces the correct output and exit status. When the failure occurs, the appropriate exit status of the 'expr' call is non-zero; however, it is incorrectly interpreted as zero, causing the configure script to exit prematurely. This was evidenced by running the test with the 'expr' wrappered in a script to log the arguments, output and exit status of each 'expr' invocation. This failure is not consistent; it takes many iterations for the effect to be realized. The failure also never occurs if the configure.test script is executed under strace. The failure does not necessarily occur in the same place within the configure script. The failure has not been shown to occur on a native GNU/Linux system to this date. It only occurs on PC/Cygwin systems. As a result, trapping the error typically involves running multiple iterations. Attached, I offer a pair of scripts designed to exhibit the failure. The attached archive contains the following files: configure.test This script was extracted from the RTEMS build enviroment and pared down to avoid requiring the entire build context. It is observed that the failure occurs in the OPTION=VALUE processing of the configure script. test-drive This script invokes configure.test under a variety of iterative and environmental controls. The scripts are suitable for execution in a chroot jail with just the /bin (cp -r /bin /jail/bin) and /tmp (mkdir /jail/tmp), as needed for bash. Execute '$ ./test-drive help' to get details on the options as well as some summary on my current thinking on this. NOTE: it is not uncommon for the script to require on the order of 100 iterations to fail. --- Summary of related threads and investigations performed to date: 1) https://sourceforge.net/tracker/?group_id=2435atid=102435func=detailaid=8 07543 Chris Johns filed a bug (with test scripts) in the MingGW project related to the same configure issue. In that filing, the failure presented under Win98, did not appear to occur in WinXP, and was affected by the order of options listed on the configure command line. 2) http://sources.redhat.com/ml/cygwin/2004-08/msg01025.html Peter Ekberg posted some work within the GGI project, and also posted some links to similar issues found in other projects like Ethereal (circa 09/2003), KimDaBa (04/2004) and Cygwin itself (10/2003). [The latter two quickly degenerated OT, unfortunately...] 3) http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html and http://www.rtems.com/ml/rtems-users/2004/september/msg00036.html Andrew DeFaria summarized a problem in Win32 desktop heap resources (circa 2002) that I initially explored (with brief success on my workstation and Scott Newell's in msg00044.html of that same thread). However, after additional tests and more failure reports, I abandoned that track to concentrate on the expr problem. Nevertheless, manipulating these resources appeared to affect the failure mode with all other things being equal. [I should also mention at this point that it seemed to me that the scripting failures increased in frequency after I killed the Explorer task (which windows promptly respawns). I have not restarted my workstation since that time. In anycase, this may simply be circumstantial] 4) http://sources.redhat.com/ml/cygwin/2002-08/msg00449.html thru http://sources.redhat.com/ml/cygwin/2002-08/msg00556.html This relates to Manfred Spraul's patch for bash related to RECYCLES_PIDS. I have observed the failure to occur under (a)sh, and bash 2.04.5, 2.05b and 3.00.0 ( I compiled them all, including enabling the RECYCLES_PIDS for bash 2.05b ). The one thing I was able to observe was that running under bash 3.00.0 had the least likelyhood of producing the error. However, under long running operations, the exact same failure occurred eventually. [the script above allows easy testing of different shells in chroot jails]. Some details related to my investigation of this can be found here (http://www.rtems.com/ml/rtems-users/2004/september/msg00059.html). I had activated the tracing/logging in (a)sh looking at the modification/use of the global exitstatus and oexitstatus. --- I end with hopes that together the good people of Cygwin and the 'net can come to an understanding of what this thing is. Best Regards, -bogdan p.s. If you should be interested in looking at my cygcheck output get it here: http://www.ngit.com/blog/csb350/cygcheck.txt configure-test.tar.bz2 Description: Binary data -- Unsubscribe info
RE: 1.5.10: expr + configure failure + testcase
Excuse me.
Please perform the following on the script:
$ sed -i '1 s/\/sh/\/bash/' test-drive
I attach an archive with the updated script.
-bogdan
begin 666 configure-test.tar.bz2
M0EIH.3%!62936=4F0T`,A1_I/__0!___\!`0``@ [EMAIL PROTECTED]/X[
MN?3^;--%\/7GN??;E7OICWN/RO4JLJTH%F4:)V!NJEP]QI-SF[CA%J #
MSCGHT:R?=OO?=[M[/[EMAIL PROTECTED];[EMAIL PROTECTED]'T^[[ND*I%0ZUF-37W,YEM6MB.SLY
M9F :6ZSMW)=1=UBH(K8QJVTZW65'=N%:D@4H[G72P[LYFP UFV.:8YVW8
MX5NACNQ6K1)E#:VZX;#32!- 3)B !#1H:2GY3RF)-M-093RFJ/$F@,AD TP
MAH TT$T$T:GJF4RGJ:32CQ0#:(H`T!H`:- ```PT$4T3)[EMAIL PROTECTED]: -
M``TIH (#1H```@ 322$(T*C1-IZ:3)C53\$RIM3U/U3:9('[EMAIL PROTECTED]
M#30``,[EMAIL PROTECTED]:9 %-,5/-33U--,C$T!/)DRGJGA,ILID]-(]1HH\2@_5,:
M@1$(: $ 1D)BGD,BGZ30%,RA-E0;-34\HRIY1D:-J@?8?O_;VS_[;4
MU@\Z,/!A*?LBCW0\!._=[55A!,8DC*,`C409%0-[EMAIL PROTECTED],A(MKBX
M?4+^WOJY^C\?]'S\:[^RT'ADG#^U/)5\7I86;TI8M04D*!$ 2,'#;3+9N
[EMAIL PROTECTED] ?GMLN+]%T$^GI;KUWOQ,8T_=8,RI_A6HK5IH,$26.)%VCZ*^(N
MJ6#[)V)7)\4M59%AFXS$I1#[9H-RVR-@\1=E1JHF4!XK/!F:C /KV20\^+
[EMAIL PROTECTED]'(33-YHO 8RR^(9Z8CU;R^F]QCYJO'KL6V6)[EMAIL PROTECTED])'X
[EMAIL PROTECTED]9GYY_C8*)ZL/'/R_2,-[Y:2C2Z\(+76J2M/[EMAIL PROTECTED](
MQ-5=\JQR(M54N,%X:[EMAIL PROTECTED]@_6ZISX?B1R*-6K6XMC28FA'$$;=%ONBVL
M0HBY?JZF1P!UPX:LV#IYASZ:VW+P7./X_/Q,0[EMAIL PROTECTED];7..8YCY3SI2K@
M\^*PZ01)W)@(ID11Q!JL 65.[%JQA=VO8*A*.R[J][M_II*3N5%;[M#=*(
M*RF+)7DVHSB[UK)(KIIS]/]KF[YE95+FXRE;;@7:]P_==Z0IX%#3;NJJQ
M=-%[Z%555^-P5\?I]QZ)[)Y',1@FUN-W+,JC_-6((?3L`9P0:
ME^?..JN:=^ULL-]+HR:73UY]:F]]ZD2\/9DHC73%LCIKGV,OE;82
MC?MKFHD\.S3,*=9#A1]*9G45.AMFEMUH@7:[TI)-SUKW4[_3L;_P?5F'
MLNVR)EE$\P\]#*5Z2R@6!U\JH2,\!KG[[E4DDD1*):]!D#1)DR),-
M4V9 39H$F19BF)TK6]0+(E.DAG(7%SUO(NS%O,@]RTKV %MT.!WX#G/
MDG%[,Y)O(KL-C/P-E_TU-4CB4!'[EMAIL PROTECTED]0ET.C'?C3EXLVSLR:2#1,S-G
M0.(#3KA;PAUTFMC[!;OH= 07'45R5Z)MU ;L7(LC-AM!#'CHF9SVR0Y;Q
M_!#S=/9NRG%?:+-QLG:YBEA]!$.5'70.:CUD-X\F[79T\V8Z:7'.PTQ
MW1RN*;:SX!?CQK=JV:=/#GHW]2K/ND4A$A'ND%%7JQ04ZY%5$LK04$* =:
M-\$4Y8 A\=]*%$0$ZA[-W3_=1;U(=R`:8J';OR]W[K'X]6,D6*W14T[
M**V%[X7T#QJ5=8LT@;#Q\\=]?[EMAIL PROTECTED]%T)_-ME]FW6;:\EQ-V_[[*[HYQ9
M$3FF)%_JBO)\- *9IAM,^%RF@@Q4B*I%0228DBHJ *!%C$_-:+!WEDR3H
M43A^K[3600T(E-$^+T..K[[\7\#Y9(3Y0$Z-#02P!0R?Q^:ZKAJD (
MX$4K2L2QLX%Q-0-IP _?\F5@)QGQPV;[EMAIL PROTECTED](0,@)O600E
M.(0D!%,A7F1`3]G8?!,G,;:;CCJQ87#QU81WH[=/K'S/B7'C[9'I;RCQ
MB PG3U B!5U8'@%5# (,71X2XI]#:OQ+ZX%0B.\W3\'?BLB4?4=U#\!N\
MU$XXDB:EP*6BU:VFKM?E[@[EMAIL PROTECTED];(LD^GHYZ1$G' :J%F(FU$%V/5FL*#'B
MQ( [EMAIL PROTECTED]/@\;3MST.LVSGQ+D'6SI?\,!78E;=
M,[74^F([EMAIL PROTECTED](/)X7N;35'1N4[)%2U?C(;UF0$;X9:G$G,)$M*:N1TCR
MM-[T2[1%F+8VXZ% (_*Y8)L:J60%A-M-^+\=V'@[[W2 *04BBR ,@,W-
M(7[:$V11M 9!9 9$(H32$J0BR75)/B0AID-=I9,9R$L(M$/9[:OJINKV
M)FH/U+Y'TFDZ^Z.US(F,/$WDT7 ;7NZ#$'!3 N+H8WMO**3F1TCDSJK
M:.AK!\96R8$1$00VW0#%\O5.#Q/2;/1\2/AZ-6IYXHTV%,#^W'JS.(?O
M)B,WS^/* .4_1_3=D'Y\#KG2OQI`)KS;=04(?I(7 HFD:E$?/MS[02
M,'U*C)^4`9BB?E!%BCVSR93JOF='?N8K1T,L*FQ\+2'4L=HB)N2V#*
M,,,2]F;@?MUPEXR0AL3^%8FV?4;(D/.D5CSA00HD?9T[S5UY:[EMAIL PROTECTED],G
MW9;:MQ/T]=*J' V/,UVOP9[/Y8Z8CKDFBO.D'[EMAIL PROTECTED],-)TS19-=T
M]L/S\=?K\WD_5]-G5VV4:SS;$XB'4#5T,YLH]+Y2(E#Z1 /+I= ?!9G
M;!Y,XQLT#%.EO](]R\]56S (,2+U#0A]B*H$C_4RY)4\^?1XGII?IEJ,3\D
M6,9=FV*O;]C=#EZ'\22^F*]U$R0N=(?O1F;NF5-I?9XRGB-!/R;)+:
M]7C+!N#E*-IYG-0#ZY^,#5%R838*'\T!BCJRHSVB:R_FM]Z[!EBG'ZSY(=*
M8X;2;;7W\/#:#KF;[EMAIL PROTECTED]:GV_$*A/,0TY,+-$OC/@516)TG*
M6NQIB;R23,8VK$HTL,2\_*6KA2%%9Z:-V:0D/=P+((#!UHF[QZAF9(OP
M213/X 9LR8XE[3-?[\G3:+;7$3K6\BNR8-LWCXH!?H*]CG#*W, 0PAJD
MD4*/CM5X#D%5 NK7AJ:O!]!KRY4K[J=F:#G+.#Z:?2OV#T),)V34,*BS_-
M=L1X@:G+C69CB)DA5*.,?Y)6P]_$QM[[J;(].1!3JBA$\ZE0UJ8MBS*(
M5WCW_Y5Y^BHJM[H:[ZJ=! MYJX80K-#X,[EMAIL PROTECTED])A\BYY?48`VNJ
M2',!(E]EE:(?XJI@(HG5+Z08:_5(@[EMAIL PROTECTED]*Q)[EMAIL PROTECTED](
MZ#X_I!6%Z?8?C(Z?`SYE([EMAIL PROTECTED])9(MJLZL?)H:MDXGEK*
M)CG%L) _F6)R*J+5IW\!VPUVJ,[EMAIL PROTECTED]YE/2.HU*)HJSN[;ID\S2,WD
M:4K.NA63V +EI.6LYH5U!4::XX1LDMPY(%?Y*Z\OV[ZBVVQV:H/'CKNZZV
M_G;G-5.!R_8$ M7MCFX993W#YB/,V[6$X7A849(LJU(RT:8)N*E-=L.
M$Q6A,.!0ZP(^*X_SP5$7PK6ZM/OZT=+B[#\4J/.=U4W] =;\\:B6[MC[
[EMAIL PROTECTED] R[7!USE?/NHTX4LC%K401RM6-=-OHF[EMAIL PROTECTED]/=ESBBCV-W,?PL]
M-54`CPUZMS)7=KS8\V=Y@I;6)=.YNZUAV44*$ZT8?.8'41-5+K,/WHG'.
M8C18O$HB;6^/;XIS03A-^VB[EMAIL PROTECTED];!)!L`6J86%4V.QESC
MK5BXZ]L8=ECSZ9M(,AV0QYL)%S?UZ,G7\Z[NYR.ZJ)[D.B`H%RVK]
MO3LQ7;C[4*$I15(([EMAIL PROTECTED]@+_'1P[G:A@/#*;U3%).*+$$*%!DEGB(K!61/W
M#3L:_75='67#!NF8N(Z7FJ:'[2$*'';$PU\?3WTUKQ'6MP12 32^_GCT5H
M`-N.N#-!BH(6ZR3%!(JGVL,D3SHG[EMAIL PROTECTED]
M17\_NTT.PI,R-!7/0NL!=23W).!TN,:$L-.$G7%:[GO1A6$CCC4,SJ=V7
M5D:[EMAIL PROTECTED]R_,\.V(V(M\S.6GR;(^-1/$C(C8FBCM5A0E.N:PL]R;
MNAQNJWX\K1GE!'[EMAIL PROTECTED]@F%0Y3,0)][5($1XEM6TN)$;NOAGRV;\
M=0'(;/+6:@T!V.'1J$[LU\HSY1OB426*Z/#IBW97C([EMAIL PROTECTED];R'KINT::N(
M!.FZBJ'1E F^M;-AA42H#BHK3S8G.VU:**1V=]34V (Q%B-S;[EMAIL PROTECTED]/
M,G@:V;185[[AAZ=6S7:FKNB*ZI(A\!'0(MHN,+G%7M,VG9101@)J-
M#QWOMF]=U%U;EZA:AIU5 ET]'HCA=(/;OTQ-4NIZUS=1!$+SH._GK!3;(
M47C*:H[EMAIL PROTECTED]';O\^CB8\U%$Y'#D*$]7)AFZWV7EKH44AGAFIIZ)X;
M\:V9I.EN-!0+5%[HQ09
mobile cygwin
Hi there, I'm trying to create custom cygwin build (about 40MBs). I mean I'm trying to collect most of shell and file tools, and have at least cygwin sshd working. I'd like to have everything on cd and when needed copy all cygwin directory structure to hard disk (not only my private pc's disk but pc's disk I work on that day - I don't want to install cygwin on each pc I got to work on) and run all the utilities and use for instance sshd for port forwarding. I'm in half way. I got all utilities working in place, batch files to add and remove registry entries for cygwin (to get proper mounting points from bash). Last thing I can't figure out is sshd. To be more specific passwd. I'd like to have one (or couple) user(s) that I can work with independently of system. I'd like to run sshd on machine I work on and I wouldn't like to worry about creating new /etc/passwd each time. I'd like to use one of defined users with known password and do what I need to do. Is that possible at all with cygwin?? user independently?? If you have any ideas, please advice. Thanks in advance, Bogdan _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- 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/
