Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in latest release
kb06...@chg211134 ~ Here's the latest test - notice it reports correctly when just "mount" is invoked. $ which mount /usr/bin/mount kb06...@chg211134 ~ $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) M: on /cygdrive/m type mvfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) kb06...@chg211134 ~ $ mount -p mount: invalid option - '' kb06...@chg211134 ~ $ -Original Message- >From: Corinna Vinschen >Sent: Aug 21, 2010 3:29 PM >To: cygwin@cygwin.com >Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >latest release > >On Aug 21 15:17, Brian Kelly wrote: >> I have a script that relies on these mount options to discover how the >> prefix is set. I did an upgrade a couple days ago, and the script broke. >> Looking in the log, I discovered the following error: >> >> $ mount -p >> mount: invalid option - '' >> >> You get the same error when I tried the other argument: >> >> $ mount --show-cygdrive-prefix >> mount: invalid option - '' >> >> This behavior is seen in the straight bash environment, outside of my >> script. Apparently with the latest update. I noticed mount work was done in >> this release New Cygwin DLL 1.7.6-1 release: >> >> - Add new mount options "dos" and "ihash" to allow overriding Cygwin >> default behaviour on broken filesystems not recognized by Cygwin. >> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >> >> - Add new mount option "bind" to allow remounting parts of the POSIX file >> hirarchy somewhere else. >> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >> >> If this option was removed, the man page is not reflecting it, and user >> documentation is not reflecting it. > >The option hasn't been removed and it still works fine for me. > >> Output from cygcheck -s -v -r > cygcheck.out is attached. > >Your cygcheck output shows that $PATH contains > >Path: C:\cygwin\usr\local\apache\bin >C:\cygwin\usr\local\bin > [...] > >prior to the Cygwin default paths. Are you shore you're running >the correct `mount'? > >Oh, and, btw., you're still running Cygwin 1.7.5, not 1.7.6, >as far as your cygcheck output is concerned. > > >Corinna > >-- >Corinna Vinschen Please, send mails regarding Cygwin to >Cygwin Project Co-Leader cygwin AT cygwin DOT com >Red Hat > >-- >Problem reports: http://cygwin.com/problems.html >FAQ: http://cygwin.com/faq/ >Documentation: http://cygwin.com/docs.html >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in latest release
Funny - setup.exe shows I have 1.7.6. I'm re-installing now. I think I know what happened. I had XWin running while doing the previous install, and the prompt occurred telling I couldn't overwrite certain files that were part of running processes. It told me I'd have to reboot - which was fine by me so I continued. Apparently something "fell down" in that whole train of events, and when the reboot later occurred, the cygwin1.dll must not have been actually replaced. I'll let you know if the re-install fixes things. -Original Message- >From: Brian Kelly >Sent: Aug 21, 2010 4:00 PM >To: cygwin@cygwin.com >Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >latest release > >kb06...@chg211134 ~ >Here's the latest test - notice it reports correctly when just "mount" is >invoked. > >$ which mount >/usr/bin/mount > >kb06...@chg211134 ~ >$ mount >C:/cygwin/bin on /usr/bin type ntfs (binary,auto) >C:/cygwin/lib on /usr/lib type ntfs (binary,auto) >C:/cygwin on / type ntfs (binary,auto) >C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) >M: on /cygdrive/m type mvfs (binary,posix=0,user,noumount,auto) >Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) > >kb06...@chg211134 ~ >$ mount -p >mount: invalid option - '' > >kb06...@chg211134 ~ >$ > > >-Original Message- >>From: Corinna Vinschen >>Sent: Aug 21, 2010 3:29 PM >>To: cygwin@cygwin.com >>Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >>latest release >> >>On Aug 21 15:17, Brian Kelly wrote: >>> I have a script that relies on these mount options to discover how the >>> prefix is set. I did an upgrade a couple days ago, and the script broke. >>> Looking in the log, I discovered the following error: >>> >>> $ mount -p >>> mount: invalid option - '' >>> >>> You get the same error when I tried the other argument: >>> >>> $ mount --show-cygdrive-prefix >>> mount: invalid option - '' >>> >>> This behavior is seen in the straight bash environment, outside of my >>> script. Apparently with the latest update. I noticed mount work was done in >>> this release New Cygwin DLL 1.7.6-1 release: >>> >>> - Add new mount options "dos" and "ihash" to allow overriding Cygwin >>> default behaviour on broken filesystems not recognized by Cygwin. >>> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >>> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >>> >>> - Add new mount option "bind" to allow remounting parts of the POSIX file >>> hirarchy somewhere else. >>> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >>> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >>> >>> If this option was removed, the man page is not reflecting it, and user >>> documentation is not reflecting it. >> >>The option hasn't been removed and it still works fine for me. >> >>> Output from cygcheck -s -v -r > cygcheck.out is attached. >> >>Your cygcheck output shows that $PATH contains >> >>Path: C:\cygwin\usr\local\apache\bin >>C:\cygwin\usr\local\bin >> [...] >> >>prior to the Cygwin default paths. Are you shore you're running >>the correct `mount'? >> >>Oh, and, btw., you're still running Cygwin 1.7.5, not 1.7.6, >>as far as your cygcheck output is concerned. >> >> >>Corinna >> >>-- >>Corinna Vinschen Please, send mails regarding Cygwin to >>Cygwin Project Co-Leader cygwin AT cygwin DOT com >>Red Hat >> >>-- >>Problem reports: http://cygwin.com/problems.html >>FAQ: http://cygwin.com/faq/ >>Documentation: http://cygwin.com/docs.html >>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >> > > >-- >Problem reports: http://cygwin.com/problems.html >FAQ: http://cygwin.com/faq/ >Documentation: http://cygwin.com/docs.html >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
It's a setup issue => Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in latest release
Ok - so I did a re-install and mount -p is back. But a setup "bug" (probably not setup.exe's fault) was discovered in the process. I first tried a re-install and once again was told cygwin1.dll could not be replaced because of a running process (thought I had killed everything). Rather than quit and start over, I pressed the continue button and re-booted the laptop when the re-install completed. mount -p was STILL broken, so something sure was amiss. Turned out I had cygserver and postgres via cygserver running. (Forgot about them). These services start automatically (along with sshd) when Windows starts up. *ALSO* I have an XWin Server in the Startup folder of the Windows Start Menu. So apparently, one of these services is starting up *BEFORE* the cygwin1.dll can be replaced by Windows at startup. Weird. My laptop has an encrypted hard disk using SafeGuard. That might have something to do with it. Anyhow, it's not a bug I have time to help chase down (unless someone else wants to take the lead on it - I'll be happy to help in that case). Otherwise let this be a lesson to ALL - setup "best practice" is to shut down ALL cygwin processes and services BEFORE running setup.exe. Otherwise ... "your mileage may vary" ... -Original Message- >From: Brian Kelly >Sent: Aug 21, 2010 3:18 PM >To: cygwin@cygwin.com >Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >latest release > > >Funny - setup.exe shows I have 1.7.6. I'm re-installing now. I think I know >what happened. I had XWin running while doing the previous install, and the >prompt occurred telling I couldn't overwrite certain files that were part of >running processes. It told me I'd have to reboot - which was fine by me so I >continued. Apparently something "fell down" in that whole train of events, and >when the reboot later occurred, the cygwin1.dll must not have been actually >replaced. I'll let you know if the re-install fixes things. > >-Original Message- >>From: Brian Kelly >>Sent: Aug 21, 2010 4:00 PM >>To: cygwin@cygwin.com >>Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >>latest release >> >>kb06...@chg211134 ~ >>Here's the latest test - notice it reports correctly when just "mount" is >>invoked. >> >>$ which mount >>/usr/bin/mount >> >>kb06...@chg211134 ~ >>$ mount >>C:/cygwin/bin on /usr/bin type ntfs (binary,auto) >>C:/cygwin/lib on /usr/lib type ntfs (binary,auto) >>C:/cygwin on / type ntfs (binary,auto) >>C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) >>M: on /cygdrive/m type mvfs (binary,posix=0,user,noumount,auto) >>Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) >> >>kb06...@chg211134 ~ >>$ mount -p >>mount: invalid option - '' >> >>kb06...@chg211134 ~ >>$ >> >> >>-Original Message- >>>From: Corinna Vinschen >>>Sent: Aug 21, 2010 3:29 PM >>>To: cygwin@cygwin.com >>>Subject: Re: 1.7.6-1: mount -p and mount --show-cygdrive-prefix broken in >>>latest release >>> >>>On Aug 21 15:17, Brian Kelly wrote: >>>> I have a script that relies on these mount options to discover how the >>>> prefix is set. I did an upgrade a couple days ago, and the script broke. >>>> Looking in the log, I discovered the following error: >>>> >>>> $ mount -p >>>> mount: invalid option - '' >>>> >>>> You get the same error when I tried the other argument: >>>> >>>> $ mount --show-cygdrive-prefix >>>> mount: invalid option - '' >>>> >>>> This behavior is seen in the straight bash environment, outside of my >>>> script. Apparently with the latest update. I noticed mount work was done >>>> in this release New Cygwin DLL 1.7.6-1 release: >>>> >>>> - Add new mount options "dos" and "ihash" to allow overriding Cygwin >>>> default behaviour on broken filesystems not recognized by Cygwin. >>>> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >>>> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >>>> >>>> - Add new mount option "bind" to allow remounting parts of the POSIX file >>>> hirarchy somewhere else. >>>> See http://cygwin.com/cygwin-ug-net/using.html#mount-table >>>> and http://cygwin.com/cygwin-ug-net/using-utils.html#mount >>>> >>>>
Data loss in Cygwin's creator?
I got this *System Error* message in my e-mail: > *plonk* > Ahh... > cgf I'm concerned that creator might be dropping some critical data. However someone more knowledgeable in these matters will have debug this. I also don't have a 64 sheet test roll installed in my bathroom. Brian Kelly -- 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: Autarkic fortune/strfile usage possible?
>> I'd like to use on other machines as well - without Cygwin. >> Any opinions? > cgf writes -> > I have one: Find another mailing list if you want to discuss ways of > not using cygwin. This is a mailing list devoted to actually *using* > cygwin. I've read a LOT of cgf's one liner's, but this one *actually* broke me up for a change! (I'm still chuckling!) Seeing as how he would likely give a gold star to someone else who would have posted this, I suggest that he give one to himself (or if the fact that he no longer works for Red Hat means he is now powerless in this regard) or Corrinna should give him one! Brian Kelly -- 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 Nightly Snapshots - NOT obvious enough
>> On Mon, Jun 07, 2004 at 02:26:49PM -0700, Lex Ein wrote: >> http://www.cygwin.com/snapshots/ >> "Cygwin Interim Snapshots" >> Whoo, racy. >> Guess I missed the party. > Ok, ok. I added a subtitle to the snapshot page to make it's true nature > more obvious. > cgf First of all - where's the 900 number? Second - where's all the pop-ups with disabled exit points when you try to navigate away from the page? Third - when is cgf re-locating to Amsterdam? Fourth - with competing sites like *bang bus* and *bang boat* should't the page be renamed to *Captain cgf's bang Linux-like environment for Windows" where innocent unsuspecing OS's are picked up and . You get the picture "WellChoice, Inc." made the following annotations on 06/08/2004 05:14:03 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: cygwin-1.5.11-1
Borrowing a line from that deeply inspirational film ... ANIMAL HOUSE: "THANK YOU SIR - MAY I HAVE ANOTHER!!??" The efforts of all involved are GREATLY appreciated! Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 09/05/2004 12:51:25 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:[ANNOUNCEMENT] Updated: cygwin-1.5.11-1 I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Christopher Faylor Red Hat, Inc. Changes since 1.5.10-3: - Fix various reported cygserver problems. (Corinna Vinschen) - Add -g/--group option to mkgroup (q.v.) (Igor Pechtchanski) - Fix some problems with rsync hangs on Windows NT class systems. (Bob Byrnes) - Fix mysterious configure script premature exit. (Pierre Humblet) - Properly zero fill file on windows 9x when file is extended. (Pierre Humblet) - Regularize errno text output. (Corinna Vinschen) - Fix handling of audio fds when duped. (Pierre Humblet) - Report correct processor-specific flags in /proc/cpuinfo. (Christopher January, Tomas Ukkonen) - Add workaround to get Cygwin working on 64-bit systems. (Corinna Vinschen, Christopher Faylor) - Fix handling of chdir with windows paths. (Pierre Humblet) - Make path handling and error checking for mount more robust. (Pierre Humblet) - Add minor speedup to spawn/exec processing. (Christophe Jaillet) - Fix shmget handling. (Corinna Vinschen) - Don't create filenames, on disk, which normal Windows interprets as "special". (Pierre Humblet, David Fritz, Christopher Faylor) - Make IPC_INFO visible only for ipc system utilities, to make it consistent with declaration of struct seminfo. (Egor Duda) - Fix usage message in ssp. (John Paul Wallington) -- 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/ "WellChoice, Inc." made the following annotations on 09/05/2004 07:53:46 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: hacked package on server
This would be "more" helpful: Do you want to not skip the package (No/Yes/Maybe)? The "Maybe" can then consult a random number routine to decide whether or not to do the operation. -Original Message- >From: Christopher Faylor <[EMAIL PROTECTED]> >Sent: Jul 16, 2007 11:52 AM >To: cygwin@cygwin.com >Subject: Re: hacked package on server > >On Mon, Jul 16, 2007 at 10:30:52AM -0500, Louis Kruger wrote: >> I also have a complaint: the dialog that notifies the user of the failed >> MD5 is not well designed. The dialog asks "Do you want to skip the >> package?" and has a yes and no button. I read it quickly and pressed no >> before thinking about it, the package went ahead and tried to install. I >> think there should be a little more effort to restrain the user from >> performing a dangerous action such as installing a package with a wrong MD5. > >Good point. The message should probably be > >Do you want to not skip the package (No/Yes)? > >cgf > >-- >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >Problem reports: http://cygwin.com/problems.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ > -- 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: Will next cygwin1.dll release have the select() fix?
Why do I feel like I'm watching an Ed Wood movie? Thank God you guys write better code than you do comedy. Suggested ad copy for "attracting" more non-contributing end-users: Cygwin! - Come for the software, stay for the BERATEMENT! :-l bits and bytes may break my code, but your 'word's will never abend me! -bk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, November 14, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: Will next cygwin1.dll release have the select() fix? On Fri, Nov 14, 2003 at 02:18:36PM -0600, Brian Ford wrote: >On Fri, 14 Nov 2003, Christopher Faylor wrote: > >> On Fri, Nov 14, 2003 at 02:10:53PM -0600, Brian Ford wrote: >> >On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote: >> >> Gold star for Brian! >> >Thanks! But, be carefull. We're both Brian :D. I thought of that a millisecond after sending the email: "Gold star for Brian Ford!" cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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: Will next cygwin1.dll release have the select() fix?
BRAVO! My hearty congratulations to Mr. Ford. I'm sure it will look good on his resume. >>> *I was actually given Brian Ford* I thought slavery in this country ended with the Civil War, or is Mr. Ford a form of *artificial intelligence*? Anyhow - how much do you want for him/it? ;-D -bk "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 11/15/2003 02:11:20 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Will next cygwin1.dll release have the select() fix? On Sat, Nov 15, 2003 at 01:37:04PM -0500, Brian Kelly wrote: >Why do I feel like I'm watching an Ed Wood movie? > >Thank God you guys write better code than you do comedy. > >Suggested ad copy for "attracting" more non-contributing end-users: > >Cygwin! - Come for the software, stay for the BERATEMENT! You're confused. There was zero comedy intended or implied in the below. I was actually given Brian Ford a gold star for answering your questions correctly. Go to the cygwin web site and look for the gold stars link. -- 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/ "WellChoice, Inc." made the following annotations on 11/15/2003 02:36:07 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 End - Will next cygwin1.dll release have the select() fix?
> Anyway, can we *please* just drop this noise now. Agreed - enough. > I'll gladly relinquish it if it'll make you feel better. HECK NO!! cgf doesn't give those out every day - and besides, in my not so humble opinion you've contributed MORE than enough to deserve one outside of this *noise* - as you put it. All kidding aside, the work done by all contributors *IS* appreciated VERY MUCH and my hat is off to you. Cygwin is improving almost daily, and it is entirely because of contributions like yours. (I hope cgf sees fit to include this with the chronology posted on the website). -bk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Ford Sent: Saturday, November 15, 2003 3:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Will next cygwin1.dll release have the select() fix? On Sat, 15 Nov 2003 [EMAIL PROTECTED] wrote: > BRAVO! > > My hearty congratulations to Mr. Ford. > > I'm sure it will look good on his resume. > > >>> *I was actually given Brian Ford* > > I thought slavery in this country ended with the Civil War, or is Mr. Ford > a form of *artificial intelligence*? > Yeah, that's it! I'm just a robot creation of Chris'. That happens automatically when you start hacking on Cygwin code, like Chris said. > Anyhow - how much do you want for him/it? > > ;-D > Sorry, not for sale. In all fairness, I did answer your question, all be it in a somewhat sarcastic manner. Reread the quote below. I'm sure it was not really deserving of a gold star. So, I'll gladly relinquish it if it'll make you feel better. Brian Ford wrote: > On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote: >> Chris Faylor wrote: >>> I'm wondering what you think the term "snapshot" means. >>> >> cvs - as opposed to setup.exe >> >What do you think the cvs repository is for? > >> So I take it I'm wrong and can get the select() fix via default setup.exe? >> >Not now, but the next release will be based off cvs. Doh! > >That is what snapshots are for, to test for a yet to be determined >future release. > >>> Standard flip answer: Definitely by December 2004. >>> >> Is there such a thing as a standard "non-flip" answer? >> > Cygwin is a voluteer effort. Releases do not happen on a schedule. > Volunteer yourself, or take what you get. > Anyway, can we *please* just drop this noise now. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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/
cpan/gcc cannot compile perl module after cygwin 1.5*
Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the default configuration just fine. Now it can't. I am aware that the entire perl IPC distribution never did ever work with cygwin - especially named pipes. However, the Semaphore module *did* - and before the 1.5* upgrade, compiled flawlessly with the default configuration. Not only that, but the resulting Semaphore.pm *worked* flawlessly as well - and is an integral part of a production system I now maintain. Luckily, the compiled binary from the previous version of cygwin/gcc combo works just as flawlessly with current 64-bit release of cygwin - but I can no longer compile it with the default installation. I have backups of the binary - so there are no real problems currently. However, since I can't and don't want to roll-back cygwin, I need to find a way to successfully compile it with the latest version of cygwin/gcc. If someone can see a quick fix - or work around - to this it would obviously be a BIG help and be much appreciated. Brian Kelly cpan> install IPC::Semaphore R unning install for module IPC::Semaphore Running make for G/GB/GBARR/IPC-SysV-1.03.tar.gz CPAN: Digest::MD5 loaded ok Checksum for /cygdrive/c/temp/.cpan/sources/authors/id/G/GB/GBARR/IPC-SysV-1.03.tar.gz ok Scanning cache /cygdrive/c/temp/.cpan/build for sizes IPC-SysV-1.03/ IPC-SysV-1.03/SysV.pm IPC-SysV-1.03/Msg.pm IPC-SysV-1.03/MANIFEST IPC-SysV-1.03/ChangeLog IPC-SysV-1.03/Makefile.PL IPC-SysV-1.03/t/ IPC-SysV-1.03/t/sem.t IPC-SysV-1.03/t/msg.t IPC-SysV-1.03/README IPC-SysV-1.03/SysV.xs IPC-SysV-1.03/Semaphore.pm Removing previously used /cygdrive/c/temp/.cpan/build/IPC-SysV-1.03 CPAN.pm: Going to build G/GB/GBARR/IPC-SysV-1.03.tar.gz Checking if your kit is complete... Looks good Writing Makefile for IPC::SysV /usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typema p SysV.xs > SysV.xsc && mv SysV.xsc SysV.c Running Mkbootstrap for IPC::SysV () cp Msg.pm blib/lib/IPC/Msg.pm p SysV.xs > SysV.xsc && mv SysV.xsc SysV.c cp Semaphore.pm blib/lib/IPC/Semaphore.pm cp SysV.pm blib/lib/IPC/SysV.pm gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3 -DVERSION=\"1.03\" -DXS_VER SION=\"1.03\" "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE" SysV.c chmod 644 SysV.bs cp SysV.bs blib/arch/auto/IPC/SysV/SysV.bs chmod 644 blib/arch/auto/IPC/SysV/SysV.bs SysV.xs: In function `XS_IPC__Msg__stat_pack': SysV.xs:69: storage size of `ds' isn't known SysV.xs: In function `XS_IPC__Msg__stat_unpack': SysV.xs:89: dereferencing pointer to incomplete type SysV.xs:92: dereferencing pointer to incomplete type SysV.xs:95: dereferencing pointer to incomplete type SysV.xs:97: dereferencing pointer to incomplete type SysV.xs:99: dereferencing pointer to incomplete type SysV.xs:101: dereferencing pointer to incomplete type SysV.xs:103: dereferencing pointer to incomplete type SysV.xs:105: dereferencing pointer to incomplete type SysV.xs:107: dereferencing pointer to incomplete type SysV.xs:109: dereferencing pointer to incomplete type SysV.xs:111: dereferencing pointer to incomplete type SysV.xs:113: dereferencing pointer to incomplete type SysV.xs:115: dereferencing pointer to incomplete type SysV.xs:117: dereferencing pointer to incomplete type SysV.xs: In function `XS_IPC__Semaphore__stat_unpack': SysV.xs:135: dereferencing pointer to incomplete type SysV.xs:138: dereferencing pointer to incomplete type SysV.xs:140: invalid use of undefined type `struct semid_ds' SysV.xs:140: dereferencing pointer to incomplete type SysV.xs:141: invalid use of undefined type `struct semid_ds' SysV.xs:141: dereferencing pointer to incomplete type SysV.xs:142: invalid use of undefined type `struct semid_ds' SysV.xs:142: dereferencing pointer to incomplete type SysV.xs:143: invalid use of undefined type `struct semid_ds' SysV.xs:143: dereferencing pointer to incomplete type SysV.xs:144: invalid use of undefined type `struct semid_ds' SysV.xs:144: dereferencing pointer to incomplete type SysV.xs:145: invalid use of undefined type `struct semid_ds' SysV.xs:145: dereferencing pointer to incomplete type SysV.xs:146: invalid use of undefined type `struct semid_ds' SysV.xs:146: dereferencing pointer to incomplete type SysV.xs:147: invalid use of undefined type `struct semid_ds' SysV.xs:147: dereferencing pointer to incomplete type SysV.xs: In function `XS_IPC__Semaphore__stat_pack': SysV.xs:158: storage size of `ds' isn't known SysV.xs: In function `XS_IPC__SysV_ftok': SysV.xs:194: `no_func' undeclared (first use in this function) SysV.xs:194: (Each undeclared identifier is reported only once SysV.xs:194: for each function it appears in.) SysV.xs:194: warning: `return' with a value, in function returning void make: *** [SysV.o] Error 1 /usr/bin/make -j3 -- NOT OK Runni
IGNORE: Re: cpan/gcc cannot compile perl module after cygwin 1.5*
Oops!! My goof - I meant Win32::Semaphore. DOH! -bk [EMAIL PROTECTED]@cygwin.com on 11/15/2003 05:10:54 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:cpan/gcc cannot compile perl module after cygwin 1.5* Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the default configuration just fine. Now it can't. I am aware that the entire perl IPC distribution never did ever work with cygwin - especially named pipes. However, the Semaphore module *did* - and before the 1.5* upgrade, compiled flawlessly with the default configuration. Not only that, but the resulting Semaphore.pm *worked* flawlessly as well - and is an integral part of a production system I now maintain. Luckily, the compiled binary from the previous version of cygwin/gcc combo works just as flawlessly with current 64-bit release of cygwin - but I can no longer compile it with the default installation. I have backups of the binary - so there are no real problems currently. However, since I can't and don't want to roll-back cygwin, I need to find a way to successfully compile it with the latest version of cygwin/gcc. If someone can see a quick fix - or work around - to this it would obviously be a BIG help and be much appreciated. Brian Kelly cpan> install IPC::Semaphore R unning install for module IPC::Semaphore Running make for G/GB/GBARR/IPC-SysV-1.03.tar.gz CPAN: Digest::MD5 loaded ok Checksum for /cygdrive/c/temp/.cpan/sources/authors/id/G/GB/GBARR/IPC-SysV-1.03.tar.gz ok Scanning cache /cygdrive/c/temp/.cpan/build for sizes IPC-SysV-1.03/ IPC-SysV-1.03/SysV.pm IPC-SysV-1.03/Msg.pm IPC-SysV-1.03/MANIFEST IPC-SysV-1.03/ChangeLog IPC-SysV-1.03/Makefile.PL IPC-SysV-1.03/t/ IPC-SysV-1.03/t/sem.t IPC-SysV-1.03/t/msg.t IPC-SysV-1.03/README IPC-SysV-1.03/SysV.xs IPC-SysV-1.03/Semaphore.pm Removing previously used /cygdrive/c/temp/.cpan/build/IPC-SysV-1.03 CPAN.pm: Going to build G/GB/GBARR/IPC-SysV-1.03.tar.gz Checking if your kit is complete... Looks good Writing Makefile for IPC::SysV /usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typema p SysV.xs > SysV.xsc && mv SysV.xsc SysV.c Running Mkbootstrap for IPC::SysV () cp Msg.pm blib/lib/IPC/Msg.pm p SysV.xs > SysV.xsc && mv SysV.xsc SysV.c cp Semaphore.pm blib/lib/IPC/Semaphore.pm cp SysV.pm blib/lib/IPC/SysV.pm gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3 -DVERSION=\"1.03\" -DXS_VER SION=\"1.03\" "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE" SysV.c chmod 644 SysV.bs cp SysV.bs blib/arch/auto/IPC/SysV/SysV.bs chmod 644 blib/arch/auto/IPC/SysV/SysV.bs SysV.xs: In function `XS_IPC__Msg__stat_pack': SysV.xs:69: storage size of `ds' isn't known SysV.xs: In function `XS_IPC__Msg__stat_unpack': SysV.xs:89: dereferencing pointer to incomplete type SysV.xs:92: dereferencing pointer to incomplete type SysV.xs:95: dereferencing pointer to incomplete type SysV.xs:97: dereferencing pointer to incomplete type SysV.xs:99: dereferencing pointer to incomplete type SysV.xs:101: dereferencing pointer to incomplete type SysV.xs:103: dereferencing pointer to incomplete type SysV.xs:105: dereferencing pointer to incomplete type SysV.xs:107: dereferencing pointer to incomplete type SysV.xs:109: dereferencing pointer to incomplete type SysV.xs:111: dereferencing pointer to incomplete type SysV.xs:113: dereferencing pointer to incomplete type SysV.xs:115: dereferencing pointer to incomplete type SysV.xs:117: dereferencing pointer to incomplete type SysV.xs: In function `XS_IPC__Semaphore__stat_unpack': SysV.xs:135: dereferencing pointer to incomplete type SysV.xs:138: dereferencing pointer to incomplete type SysV.xs:140: invalid use of undefined type `struct semid_ds' SysV.xs:140: dereferencing pointer to incomplete type SysV.xs:141: invalid use of undefined type `struct semid_ds' SysV.xs:141: dereferencing pointer to incomplete type SysV.xs:142: invalid use of undefined type `struct semid_ds' SysV.xs:142: dereferencing pointer to incomplete type SysV.xs:143: invalid use of undefined type `struct semid_ds' SysV.xs:143: dereferencing pointer to incomplete type SysV.xs:144: invalid use of undefined type `struct semid_ds' SysV.xs:144: dereferencing pointer to incomplete type SysV.xs:145: invalid use of undefined type `struct semid_ds' SysV.xs:145: dereferencing pointer to incomplete type SysV.xs:146: invalid use of undefined type `struct semid_ds' SysV.xs:146: dereferencing pointer to incomplete type SysV.xs:147: invalid use of undefined type `struct semid_ds' SysV.xs:147: dereferencing pointer to incomplete type SysV.xs: In function `XS_IPC__Semaphore__stat_pack': SysV.xs:158: storage size of `ds' isn't known SysV.xs: In function `XS_IPC__SysV_ftok': SysV.xs:194: `no_func' undeclared
trying again - cpan/gcc cannot compile perl module after cygwin 1.5*
Before the upgrade to 1.5* - 64 bit cygwin, this used to compile with the default configuration just fine. Now it can't. I am aware that the entire perl libwin32-0.191 distribution never did work completely with cygwin - especially named pipes. However, the Win32::Semaphore module *did* - and before the 1.5* upgrade, compiled flawlessly with the default configuration. Not only that, but the resulting Win32::Semaphore.pm *worked* flawlessly as well - and is an integral part of a production system I now maintain. Luckily, the compiled binary from the previous version of cygwin/gcc combo works just as flawlessly with the current 64-bit release of cygwin - but I can no longer compile it with the default installation. I have backups of the binary - so there are no real problems currently. However, since I can't and don't want to roll-back cygwin, I need to find a way to successfully compile it with the latest version of cygwin/gcc. If someone can see a quick fix - or work around - to this it would obviously be a BIG help and be much appreciated. Of course I'm aware that cygwin is now *64* bit compiled, and that I'm looking to compile a *32* bit module. So I guess my first question, is there backward compatibilty? And, if there is, how can I invoke it for successful compilation? Also - any hope that the default installation will ever again compile this, or is there now a need for a Win64::Semaphore module? Brian Kelly - make cp Semaphore.pm blib/lib/Win32/Semaphore.pm /usr/bin/perl.exe /usr/lib/perl5/5.8.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.0/ExtUtils/typema p -typemap typemap Semaphore.xs > Semaphore.xsc && mv Semaphore.xsc Semaphore.c gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O3 -DVERSION=\"1.02\" -DXS_VER SION=\"1.02\" "-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE" Semaphore.c Semaphore.c: In function `XS_Win32__Semaphore_release': Semaphore.c:139: warning: cast to pointer from integer of different size Running Mkbootstrap for Win32::Semaphore () chmod 644 Semaphore.bs rm -f blib/arch/auto/Win32/Semaphore/Semaphore.dll LD_RUN_PATH="" ld2 -s -L/usr/local/lib Semaphore.o -o blib/arch/auto/Win32/Semaphore/Semaphore.dll /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a gcc -shared -o Semaphore.dll -Wl,--out-implib=libSemaphore.dll.a -Wl, --export-all-symbols -Wl,--enab le-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Semaphore.o /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a Creating library file: libSemaphore.dll.a Semaphore.o(.text+0x208):Semaphore.c: undefined reference to `_CreateSemaphoreA' Semaphore.o(.text+0x620):Semaphore.c: undefined reference to `_OpenSemaphoreA' Semaphore.o(.text+0x939):Semaphore.c: undefined reference to `_CloseHandle' Semaphore.o(.text+0xc6a):Semaphore.c: undefined reference to `_ReleaseSemaphore' collect2: ld returned 1 exit status perlld: *** system() failed to execute gcc -shared -o Semaphore.dll -Wl,--out-implib=libSemaphore.dll.a -Wl, --export-all-symbols -Wl,--enab le-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Semaphore.o /usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE/libperl.dll.a make: *** [blib/arch/auto/Win32/Semaphore/Semaphore.dll] Error 1 [EMAIL PROTECTED] /cygdrive/c/temp/.cpan/build/libwin32-0.191/Semaphore "WellChoice, Inc." made the following annotations on 11/15/2003 05:41:41 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: snapshot cygwin1-20031212.dll.bz2
Before you go "do-o-o-o-o-o-o-own" - can you release 1.5.6? I'm waiting. ;-) Brian Kelly aka: cgf's first ever *Black Hole* recipient (If he were to give out such a thing). "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 12/17/2003 03:08:58 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: snapshot cygwin1-20031212.dll.bz2 On Wed, Dec 17, 2003 at 02:02:59PM -0500, Igor Pechtchanski wrote: >/* CGF: going down. > > Copyright 2003 Red Hat, Inc. > >This text is part of Cygwin. > >This composition is a copyrighted work licensed under the terms of the >Cygwin license. Please consult the file "CYGWIN_LICENSE" for >details. */ > > >You better watch out, you better back up, >Because all support for Cygwin will stop: >CGF is go-oing down... >He's one of the thugs who manage Cygwin, >He adds all the bugs because he is mean: >CGF is go-oing down... >He knows the ins of signals, he knows both spawn() and fork() >He has his own environment that makes all programs work... > >His manner is rude, he lurks on the lists, >He'll make you spit food and clench both your fists: >CGF is go-oing down... >He has the gall not to spend all his time >On fixing our bugs and this is a crime: >CGF is go-oing down... >Cygwin will just be better with no CGF, >Until the day you find a bug and run screaming WTF? > >You better watch out, you better back up, >Because all support for Cygwin will stop: >CGF is go-oing do-o-o-o-o-o-o-own! This is the funniest thing I have ever seen on this list, no exceptions. I'm going to send it to everyone I know. Of course, they'll all say "Huh? You aren't mean." but they have never read the cygwin lists... cgf P.S. The copyright was a great touch! -- 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/ "WellChoice, Inc." made the following annotations on 12/17/2003 04:45:46 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
(very off-topic laptop aside) - my experience
cgf - I don't know how much any of this will help, especially since I fancy myself rather low on the list of those you would entertain for *advice* - anyhow, here goes. I sympathize with you *completely* about struggling to find a way to multi-task your life. I work at least a 100 or more hours a work on the computer routinely - and am married (no kids yet). Before I even got married, I KNEW I'd have to come up with a creative solution if I wanted to continue working those kind of hours AND keep a wife *relatively* (I entertain doubts that ANY wife is ever *truly*) happy. I've been enjoying my solution for three years now, and its been BEYOND wonderful. It's exceeded my expectations a hundred fold. Basically I saved my money and bought a commercial grade projector. I own an Infocus 950 with a 2400 Lumen value. It originally retailed for $11,000.00. I bought it on closeout for the unbelievable price of $4000.00 from B&H in Manhattan. The quality is outstanding, and with the high lumen rating, the sun can be shining in the window and the screen quality is undiminished. My living room is small, so I had to buy a screen since I had no white wall big enough. A 100 inch portable screen from Da-Lite ran $700.00. It's worth every penny. It actually covers a window - and when not in use, can be collapsed in 5 seconds to again show the window. I spent $1000.00 buying a new three piece sectional and did not use the middle section. Instead I moved together the couch and left-armed chaise lounge to create a rather unique living room *bed*. I built a stand-alone rack system from PVC and 2 inch electrical conduit (all from Home Depot) to suspend the projector AND computer from the ceiling since you don't want a very long digital monitor cable between the video card and the projector. The digital cable I bought cost $80.00 and is only six feet long. It was the longest one I could find without getting one custom made. Otherwise, beside the projector cable and screen, everything else can be bought routinely at Best Buy or CompUSA. Fact is, I custom built my computer myself so I could build in exactly what I wanted. I bought the ATI All-In-Wonder Card so that I could pipe DirecTV directly into the computer. Now I have not only a VERY comfortable and productive work environment, but also a KICK-AA$$S home theater entertainment system that LAUGHS at all the money people are spending on new plasm TVs. (It does HDTV as well). I run 2000 Server on the machine so I can do RAID and other high end things. I have NFL Sunday ticket, so I can watch my pathetic Detroit Lions, drink a beer, check my e-mail for more cgf meanness and work on my projects all the while *reclined* on my chaise lounge. I use a Logitech wireless ergonomic keyboard and wireless trackball mouse. Since the computer is suspended from the ceiling, the actual range is increased to almost ten feet. That's ten feet radius, so in fact I can use the keyboard and mouse with a twenty foot circle - pretty much covers the whole room. Because of the sectional setup, my wife can sit next to me and watch TV - we can share a blanket, watch a DVD -WHILE- I debug and code my Perl projects (using cygwin of course). I can be online with work via secure dial-up (because I'm a contractor they won't give me VPN - stupid). I also have a laptop, which I just plug into the DSL router and access via DameWare Mini Remote Control and/or cygwin (ssh, nfs - you know the drill). (Laptops - Darn things fry your mannhhood off when parked in your lap for too long - but a wireless keyboard can sit there ALL day!) Because of this setup, I'm always in the MIDDLE of the action. My wife never feels alone and abandoned and often cuddles with me to read a book while I work. When I'm away, she uses the *construction* as she calls it to shop e-bay, build puzzles on JigZone.com, e-mail her friends and family, etc. She loves it as much as I do. This setup has DEFINITELY increased my productivity 25-30%, PLUS upped my quality of life SUBSTANTIALLY. Anyone who sees my setup is blown away impressed - you can actually see the *awe* in their eyes. And the whole setup cost less than $10,000 in total to build (not to mention a few hundred hours of time to build and setup). Not cheap by any stretch, but something I now CAN'T POSSIBLY imagine living without. I'd recommend this solution to anyone who does computing for a living (and anymore that includes almost everyone). There is a drawback however - putting in a new lamp cost a $1000.00. OUCH! But when considering how much I use it, it's actually a small price to pay. As for the computer, because it's an ordinary small server case housing common components. If something goes wrong I just swap it out. I do nightly incremental backups to an external hard disk via USB2 and NovaBack. You should SERIOUSLY consider something similar - if you can swing it. Brian Kelly -Origi
Re: [ANNOUNCEMENT] Updated: cygwin-1.5.6-1
Thank you cgf - I've been eagerly awaiting this. And thanks to all who have contributed to bringing this release about. I know it's a big one with a lot of "deep in the bowels of the code" changes. Should be the best Cygwin yet. By the way Chris, when will 1.5.7 be ready? ;-)( Anyone wanting another Gold Star - feel free to sarcastically answer this question for Chris! ) Regards, Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 01/19/2004 10:56:41 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:[ANNOUNCEMENT] Updated: cygwin-1.5.6-1 I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. I'd like to send a special thanks to Thomas Pfaff who is stepping down as the cygwin pthreads maintainer. His efforts in improving pthreads functionality were greatly appreciated. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Christopher Faylor Red Hat, Inc. Changes since 1.5.5-1: - Implement mknod. (Christopher Faylor) - Renumber many major/minor device numbers to be more like linux. (Christopher Faylor) - Revamp signal processing to allow beginnings of ability to send signals to threads. (Christopher Faylor) - Create shared memory regions in appropriate name space and with ACLs explicitly including their owner. (Pierre Humblet) - Protect tty access from unauthorized users. (Pierre Humblet, Christopher Faylor) - Add some missing entries to /usr/include/paths.h. (Christopher Faylor) - Add some missing entries to /usr/include/tzfile.h. (Christopher Faylor) - Fix problems with failing exec in a vfork. (Christopher Faylor) - Set errno to E2BIG if command line is longer than the CreateProcess limit. (Corinna Vinschen) - mmap fixes. (Corinna Vinschen) - Implement TIOCLINUX ioctl. (Pavel Tsekov) - Fix problem with TIOCGWINSZ. (Christopher Faylor) - Reimplement sched_rr_get_interval for NT systems. (Vaclav Haisman) - Fix some thread initialization races for stdio. (Christopher Faylor) - Correctly define MAP_FAILED as void *. (Yitzchak Scott-Thoennes) - Fix problems programs which need a console available when running on a pty. (Christopher Faylor) - Don't send SIGHUP on CTRL_LOGOFF_EVENT to processes running in invisible Windows stations (like services). (Corinna Vinschen) - Add escape sequences for codepage ansi <-> oem switching for ncurses frame drawing capabilities. (Micha Nelissen, Corinna Vinschen) - Implement System V shm, sem, msg handling in cygserver. (Corinna Vinschen) - Fix return value from FIONBIO ioctl. (Christopher Faylor) - Don't clobber O_APPEND when both O_NONBLOCK/O_NDELAY are set for F_SETFL. (Brian Ford) - Disallow filenames consisting entirely of three or more dots. (Corinna Vinschen) - Encode filenames consisting of more than two dots for managed mode. (Igor Pechtchanski) - Make tmpfile 64-bit aware. (Corinna Vinschen) - Correctly define *64_MAX. (Corinna Vinschen) - Fix Windows 95 handling of some network functions. (Corinna Vinschen) - Don't open a directory which lacks read privileges. (Christopher Faylor) - Implement vwarnx, vwarn, warn, warnx, verr, verrx, err, errx. (Corinna Vinschen) - Fix handling of freerange cygthreads which caused occasional hangs. (Christopher Faylor) - Fix utmp handling so that login/logout are correctly recorded. (Corinna Vinschen) - Implement getprogname, setprogname. (Corinna Vinschen) - Raise SIGSYS if cygserver is not running for some cygserver-specific calls. (Christopher Faylor) - Default to always checking for cygserver. (Christopher Faylor) - Add installation instructions for cygserver. (Corinna Vinschen) - Correct api major version check so that newer dlls will work with older apps but not vice versa. (Christopher Faylor) - Implement sigwait. (Christopher Faylor) - Implement flock. (Nicholas Wourms) - Make fcntl 64-bit aware. (Corinna Vinschen) - Remove polling loop for serial tcflush which caused "hangs". (Brian Ford) - Allow multiple path
cygwin-1.5.6-1 Vim now broken
I installed the new 1.5.6-1 and rebooted. I then went to edit a file with vim. I changed one line of code and went to save the file. This is what happened: - vi FA_lib.pm 'Vim: Caught deadly signal SEGV Vim: preserving files... Basically I cannot use Vim to edit files - as it now stands. Used setup.exe to backed out to 1.5.5-1, rebooted - and Vim is back to full functionality. Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 01/19/2004 10:56:41 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:[ANNOUNCEMENT] Updated: cygwin-1.5.6-1 I've made a new version of the Cygwin DLL and associated utilities available for download. As usual, a list of what has changed is below. I'd like to send a special thanks to Thomas Pfaff who is stepping down as the cygwin pthreads maintainer. His efforts in improving pthreads functionality were greatly appreciated. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Christopher Faylor Red Hat, Inc. Changes since 1.5.5-1: - Implement mknod. (Christopher Faylor) - Renumber many major/minor device numbers to be more like linux. (Christopher Faylor) - Revamp signal processing to allow beginnings of ability to send signals to threads. (Christopher Faylor) - Create shared memory regions in appropriate name space and with ACLs explicitly including their owner. (Pierre Humblet) - Protect tty access from unauthorized users. (Pierre Humblet, Christopher Faylor) - Add some missing entries to /usr/include/paths.h. (Christopher Faylor) - Add some missing entries to /usr/include/tzfile.h. (Christopher Faylor) - Fix problems with failing exec in a vfork. (Christopher Faylor) - Set errno to E2BIG if command line is longer than the CreateProcess limit. (Corinna Vinschen) - mmap fixes. (Corinna Vinschen) - Implement TIOCLINUX ioctl. (Pavel Tsekov) - Fix problem with TIOCGWINSZ. (Christopher Faylor) - Reimplement sched_rr_get_interval for NT systems. (Vaclav Haisman) - Fix some thread initialization races for stdio. (Christopher Faylor) - Correctly define MAP_FAILED as void *. (Yitzchak Scott-Thoennes) - Fix problems programs which need a console available when running on a pty. (Christopher Faylor) - Don't send SIGHUP on CTRL_LOGOFF_EVENT to processes running in invisible Windows stations (like services). (Corinna Vinschen) - Add escape sequences for codepage ansi <-> oem switching for ncurses frame drawing capabilities. (Micha Nelissen, Corinna Vinschen) - Implement System V shm, sem, msg handling in cygserver. (Corinna Vinschen) - Fix return value from FIONBIO ioctl. (Christopher Faylor) - Don't clobber O_APPEND when both O_NONBLOCK/O_NDELAY are set for F_SETFL. (Brian Ford) - Disallow filenames consisting entirely of three or more dots. (Corinna Vinschen) - Encode filenames consisting of more than two dots for managed mode. (Igor Pechtchanski) - Make tmpfile 64-bit aware. (Corinna Vinschen) - Correctly define *64_MAX. (Corinna Vinschen) - Fix Windows 95 handling of some network functions. (Corinna Vinschen) - Don't open a directory which lacks read privileges. (Christopher Faylor) - Implement vwarnx, vwarn, warn, warnx, verr, verrx, err, errx. (Corinna Vinschen) - Fix handling of freerange cygthreads which caused occasional hangs. (Christopher Faylor) - Fix utmp handling so that login/logout are correctly recorded. (Corinna Vinschen) - Implement getprogname, setprogname. (Corinna Vinschen) - Raise SIGSYS if cygserver is not running for some cygserver-specific calls. (Christopher Faylor) - Default to always checking for cygserver. (Christopher Faylor) - Add installation instructions for cygserver. (Corinna Vinschen) - Correct api major version check so that newer dlls will work with older apps but not vice versa. (Christopher Faylor) - Implement sigwait. (Christopher Faylor) - Implement flock. (Nicholas Wourms) - Make fcntl 64-bit aware. (Corinna Vinschen) - Remove polling loop for serial tcflush which caused "hangs". (Brian Ford) - Allow multiple pathnames on the cy
I post NOT to condemn cgf ...
... but to actually bestow my praise. First I would like to drag up some mud from the past: > On Thu, Aug 07, 2003 at 12:52:53PM -0400, [EMAIL PROTECTED] wrote: >> Ah well, someday the denial will end, or the problem will get fixed >> unintentionally when some other change is made and the "cygworld will >> go on". cgf: > If cygwin triggers a windows problem that does not mean > that it is a cygwin problem no matter how hard that is for you to > understand. > I fix all sorts of problems in cygwin which are really windows problems > but, > golly gee, if I can't duplicate them, I can't fix them. And, my > willingness > to debug some things is limited. If it takes running a perl script every > five minutes for a day to duplicate the problem, then that is not something > that I'm going to do anytime soon. > This is not denial. This is a refusal to take a large amount of my time > to find a workaround to a windows problem. http://sources.redhat.com/ml/cygwin/2003-08/msg00442.html Heh, heh - well cygwin fans, I'd like to report that as of 1.5.6-1, it *appears* that numerous memory and process hanging problems I've been having since the dawn of time have *suddenly* disappeared! I have yet to fully determine if I can dispense with RAMpage, but so far things look VERY encouraging. Once again I'd like to thank cgf, Corrina, Igor, and all other contributor's for their efforts in fixing this *WINDOWS* problem. ;-) Brian Kelly "WellChoice, Inc." made the following annotations on 01/24/2004 09:39:19 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 post NOT to condemn cgf ...
Igor - Are those IBM or NYU Lawyers?? I actually now work for IBM Global Services myself. Even though IBM advertises themselves these days as *open source friendly* - so to speak, your la-la land reference certainly raises suspicions - and concerns. (I know this off topic - just wunder'in is all). Brian Kelly "Igor Pechtchanski" <[EMAIL PROTECTED]> on 01/24/2004 10:13:22 AM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: I post NOT to condemn cgf ... On Sat, 24 Jan 2004 BrianKellyEmpirebluecom wrote: > ... but to actually bestow my praise. > > First I would like to drag up some mud from the past: > > > On Thu, Aug 07, 2003 at 12:52:53PM -0400, BrianKellyempirebluecom wrote: Umm, even though it's your own address, please don't quote raw e-mail addresses in messages. Let's not make the spam harvesters' life any easier... > >> Ah well, someday the denial will end, or the problem will get fixed > >> unintentionally when some other change is made and the "cygworld will > >> go on". > > cgf: > > If cygwin triggers a windows problem that does not mean > > that it is a cygwin problem no matter how hard that is for you to > > understand. > > > I fix all sorts of problems in cygwin which are really windows > > problems but, golly gee, if I can't duplicate them, I can't fix them. > > And, my willingness to debug some things is limited. If it takes > > running a perl script every five minutes for a day to duplicate the > > problem, then that is not something that I'm going to do anytime soon. > > > This is not denial. This is a refusal to take a large amount of my time > > to find a workaround to a windows problem. > > http://sources.redhat.com/ml/cygwin/2003-08/msg00442.html > > Heh, heh - well cygwin fans, I'd like to report that as of 1.5.6-1, it > *appears* that numerous memory and process hanging problems I've been > having since the dawn of time have *suddenly* disappeared! I have yet > to fully determine if I can dispense with RAMpage, but so far things look > VERY encouraging. Good to hear that. > Once again I'd like to thank cgf, Corrina, Igor, and all other > contributor's for their efforts in fixing this *WINDOWS* problem. ;-) > > Brian Kelly FTR, I had nothing to do with fixing this problem. My new copyright assignment is still in the lawyers' la-la land, so I didn't contribute any Cygwin library code lately. I'd say Pierre and maybe Thomas (Pfaff) deserve some credit here, in addition, of course, to CGF and Corinna. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton "WellChoice, Inc." made the following annotations on 01/24/2004 11:44:54 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 processes and system'ed processes using 100% CPU
Try upgrading to 1.5.6-1 and retest. A lot of things causing aberrant CPU and memory using and process hangs have been fixed with this release. No promises that it covers your problem, but anyone reporting problems with older versions of the cygwin1.dll is only going to be told UPGRADE before their told anything else. Brian Kelly "Steven Hartland" <[EMAIL PROTECTED]>@cygwin.com on 01/27/2004 09:43:35 AM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:cygwin processes and system'ed processes using 100% CPU General question has anyone else seen processes running under cygwin using 100% CPU when the shouldn't. The background is cygwin 1.5.5 I have a perl script which monitors process cpu levels. It does this using serveral system calls to other utils, ps, vmstat and pslist ( win32 app from sysinternals ). The script samples every minute recording the results. Now 99% of the time all is fine but sometime when actually running ( every minute ) it and the utils it spawns most notablly pslist use 100% cpu. So much so that if you have the desktop open it will freeze for the few seconds that its sampling for. Its very strange once its doing it it will continue to do so for each sample until restarted. The only pattern I can see so far is that it tends to happen when said script is started from sub shell script via a ssh -l user "restart.sh" Anyone seen anything similar? Alternatively what do people think is the best approch to find the issue? On FreeBSD truss would be my first port of call. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] (See attached file: cygcheck.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/ "WellChoice, Inc." made the following annotations on 01/27/2004 09:52:55 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement cygcheck.txt 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: Plausibility of sendmail?
"Brian Dessent" <[EMAIL PROTECTED]>@cygwin.com on 02/02/2004 01:10:44 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:"'Cygwin List'" <[EMAIL PROTECTED]> cc: Subject:Re: Plausibility of sendmail? >> If your intent is to use Windows+Cygwin+sendmail as a production mail >> server, then you would be much better served (no pun intended) running >> it on a native posix OS like Linux or FreeBSD Seems to me you have not worked for many Fortune 500 size organizations - where almost ALL your hardware and software purchasing decisions are made by folks who *PRIDE* themselves on their *LACK* of technical expertise - as if such were somehow evidence of their inability to *MANAGE*. In fact, being a technical guru can often be career death in such places as the *can't do's* endlessly convince themselves that the *can do's* can't "manage people". Which begs the question - "WHAT DOES CHOOSING HARDWARE HAVE TO DO WITH *MANAGING PEOPLE*" But they do it anyway. And of course when such *beings* make such decisions, they do so with assumptions like "all open source is BAD" (while their web servers are running Apache), and the CHEAPEST thing is *GOOD* - Intel rather than Sun or HP. Oh, but we can't run Linux because that's *bad* *unsupported* open source!! Then - their job done, and budget shot, they give a nearly impossible task to their *inferior guru's* that really should only be done in a Unix enviroment - enter CYGWIN. Of course it's *bad* open source, but now the *manager* has promised his/her management that this new functionality would be ready by week's end - without consulting the guru's first. So cygwin is agreed to as a *temporary* solution (with the understanding that temporary in such organizations could be two decades instead of three). This is how a need for something like sendmail on cygwin could conceivably come about - happens ALL the time. Joaquin wrote: > > I check the FAQ and I couldn't find any reference to this. I noticed > that exim is there, kewl!, but what about sendmail? Was there any work > on porting this? > > BTW, I noticed that SFU3.5 seems to have a version of sendmail. Maybe you could elaborate a little on why you want sendmail. To my knowledge there has been no work done to even begin considering packaging sendmail for Cygwin, at least not officially (i.e. supported by this mailing list, cygwin.com, and the setup.exe program.) Someone, somewhere might have done it and succeeded, but you're at the mercy of Google in that case. Part of me really wants to ask why in god's name you'd want to inflict the utter crapulence of sendmail onto an otherwise innocent system, but that's really just being snide. If your intent is to use Windows+Cygwin+sendmail as a production mail server, then you would be much better served (no pun intended) running it on a native posix OS like Linux or FreeBSD, as there is a significant performance and security impact of emulating Posix under Windows. If you're just after 'sendmail compatibility' then both ssmtp and exim provide symbolic links to /usr/sbin/sendmail. So any script or other type of app that wants to just send out email by invoking the sendmail command should work fine. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 02/02/2004 07:02:31 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Plausibility of sendmail?
>> If someone is crazy enough to want a production mailserver with Cygwin, >> let them run Exim. Point well taken. Having limited experience with mail servers in general, I will certainly keep your advice filed away in the ole noodle for future reference. Of course a lot of reasons that *crap* persists is because there's a lot of folks who are familiar with and experienced with such *crap*. For someone under the gun to come up with a quick fix, inevitably they will attempt to implement the familiar. If sendmail REALLY deserves to die, then keeping it out of the Cygwin distribution is something I would understand, and probably support (as long as there are advertised alternatives of course!) Brian Kelly "Brian Dessent" <[EMAIL PROTECTED]>@cygwin.com on 02/02/2004 09:33:56 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Plausibility of sendmail? [EMAIL PROTECTED] wrote: > Seems to me you have not worked for many Fortune 500 size organizations - > where almost ALL your hardware and software purchasing decisions are made > by folks who *PRIDE* themselves on their *LACK* of technical expertise - as > if such were somehow evidence of their inability to *MANAGE*. In fact, > being a technical guru can often be career death in such places as the > *can't do's* endlessly convince themselves that the *can do's* can't > "manage people". Which begs the question - "WHAT DOES CHOOSING HARDWARE > HAVE TO DO WITH *MANAGING PEOPLE*" But they do it anyway. And of > course when such *beings* make such decisions, they do so with assumptions > like "all open source is BAD" (while their web servers are running Apache), > and the CHEAPEST thing is *GOOD* - Intel rather than Sun or HP. Oh, but we > can't run Linux because that's *bad* *unsupported* open source!! Yes, PHB types can make really terrible decisions. That doesn't mean that because they're in charge those plans should become feasible, just because "that's what the bossman wants." My statement was only that "you'd be much better served..." with a native posix OS, especially where security and performance are required such as in a busy mail server in the DMZ. > enviroment - enter CYGWIN. Of course it's *bad* open source, but now the > *manager* has promised his/her management that this new functionality would > be ready by week's end - without consulting the guru's first. So cygwin is > agreed to as a *temporary* solution (with the understanding that temporary > in such organizations could be two decades instead of three). > > This is how a need for something like sendmail on cygwin could conceivably > come about - happens ALL the time. If someone is crazy enough to want a production mailserver with Cygwin, let them run Exim. I guess my point was more that "sendmail is an old, crufty, impossible to comprehend pile of rotten bits" and not "Cygwin shouldn't have MTA packages available because it's unsuitable for production use." In other words, I view anything that could hasten (even if infinitesimally) the demise of sendmail as a feature and not a bug. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 02/02/2004 10:07:12 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Plausibility of sendmail?
> Andrew DeFaria wrote: > If they are so clueless as you suggest then one has to wonder why you > tell them that you're running a Linux OS and using sendmail?!? They "know" that Linux is *open source* and *dangerous* - because that's what the VERY political Server Team (who have sold out to Microsoft and all their propaganda) tells them. The more Wintel boxes, the more *power* they have. Since their job ends once the box is powered up and imaged with the *approved and 'supported' corporate load*, their job is done. They could CARE-A-LESS about anyone else's needs or problems. They run their own monitoring software on the box to make sure there is no un-scheduled downtime or lack of disk space. Trying to put Linux on the box would DEFINITELY be noticed - and would probably result in dismissal. Beyond that - they (Server Team) are'nt concerned about how the box is actually used (assuming of course that you have been designated the owner of the *resource* [which is different from owning the *box* itself - go figure]). The Server Team has more political clout because they own so *many* boxes, where you own only a *couple* of resources. Of course all the *boxes* are simple clones, but that little detail is overlooked by upper management. It's all a numbers game. So the Server Team's arguments win out over yours 98% of the time. Surely someone who manages a fleet of Cessna's knows more about flying than one guy in an F-18! - or so the thinking apparently goes. >> Brian.Kelly wrote: >> Seems to me you have not worked for many Fortune 500 size >> organizations - where almost ALL your hardware and software purchasing >> decisions are made by folks who *PRIDE* themselves on their *LACK* of >> technical expertise - as if such were somehow evidence of their >> inability to *MANAGE*. In fact, being a technical guru can often be >> career death in such places as the *can't do's* endlessly convince >> themselves that the *can do's* can't "manage people". Which begs the >> question - "WHAT DOES CHOOSING HARDWARE HAVE TO DO WITH *MANAGING >> PEOPLE*" But they do it anyway. And of course when such >> *beings* make such decisions, they do so with assumptions like "all >> open source is BAD" (while their web servers are running Apache), and >> the CHEAPEST thing is *GOOD* - Intel rather than Sun or HP. Oh, but we >> can't run Linux because that's *bad* *unsupported* open source!! >> >> Then - their job done, and budget shot, they give a nearly impossible >> task to their *inferior guru's* that really should only be done in a >> Unix enviroment - enter CYGWIN. Of course it's *bad* open source, but >> now the *manager* has promised his/her management that this new >> functionality would be ready by week's end - without consulting the >> guru's first. So cygwin is agreed to as a *temporary* solution (with >> the understanding that temporary in such organizations could be two >> decades instead of three). >> >> This is how a need for something like sendmail on cygwin could >> conceivably come about - happens ALL the time. > Andrew DeFaria wrote: > If they are so clueless as you suggest then one has to wonder why you > tell them that you're running a Linux OS and using sendmail?!? > Otherwise simply get exim and use it. Works fine. -- If you think that there is good in everybody, you haven't met everybody. "WellChoice, Inc." made the following annotations on 02/02/2004 01:08:25 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: localtime_r not returning local time
YEA! - I need this fix since I use the localtime feature of perl and have been stuck with 5.8.0 (and rolling back to 5.6 required complete re-installation of all other CPAN modules) - which had been removed from setup. Anyhow THANK YOU!!! ( I know I should be a nice guy and test the snapshot - but unfortunately I don't a suitible test environment available at the moment. ) ( BURNING QUESTION - Are *THANK YOU's* from non-contributors ... off - topic??? ) Brian Kelly Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: localtime_r not returning local time On Fri, Feb 13, 2004 at 12:40:12PM +0100, Gerrit P. Haase wrote: >Yitzchak wrote: >>On Thu, Feb 12, 2004 at 01:10:03PM -0800, Rafael Kitover wrote: >>>Would it be a lot of overhead to have something like tzset be called in >>>the bootstrap code for launching Cygwin programs? Or maybe just have a >>>DLL global default, based on windows time zone, and just allow >>>processes to reset it for themselves (and any children.) > >>Either would be better than nothing. I'm very curious to know what >>various flavors of unix do. As I said, my reading of susv3 is that TZ >>should be checked with every call to localtime_r(). > >If tzset() should be called in localtime_r() it is a bug in newlib and >should be included there. localtime_r doesn't come from newlib. It's a cygwin routine. I checked in a fix a few days ago. http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/localtime.cc.diff?cvsroot=src&r1=1.10&r2=1.11 -- 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/ "WellChoice, Inc." made the following annotations on 02/13/2004 10:14:45 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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.8
The answer to this question was of such profound and ineffable importance that it earned the distinguished Mr. Brian Ford a GOLD STAR for his brilliant, luminous exposition of cgf's sagacious guiding principles. http://cygwin.com/ml/cygwin/2003-11/msg00601.html The forever humbled, Brian Kelly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of utomo Sent: Monday, February 16, 2004 5:50 AM To: [EMAIL PROTECTED] Subject: Cygwin 1.5.8 Hi, As I know many people having problems with current 1.5.7 version or 1.5.6. Is there any estimation schedule for cygwin 1.5.8 ? Thanks, Utomo -- 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: Running cygwin cron under WinXP SP1
Be sure you leave a blank line at the bottom of the crontab. This a little detail that is often overlooked - but one that would have been discovered with a little research on unix cron. (cron of course has *life* outside of cygwin) I'm not at all suggesting that this is the problem - just one more thing to be aware of. Brian Kelly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thorsten Kampe Sent: Thursday, February 19, 2004 7:07 AM To: [EMAIL PROTECTED] Subject: Re: Running cygwin cron under WinXP SP1 * Russell Hind (2004-02-19 10:55 +0100) > I have just installed the latest cygwin and set up cron to run using > > cygrunsrv -I cron -p /usr/sbin/cron -a -D > cygrunsrv -S cron > > It is running as a service (both in XP task manager and in ps -ef) > > But I can't get it to execute commands. I have tried a crontab as both > /etc/crontab and /var/cron/tabs/Russell How did you create those? crontab -e for the latter? You know that the system-wide crontab has a additional field for the user? cron logs tho /var/whatever and into the eventviewer. Please consult those two logs and explain further "can't get it to execute commands". Try redirecting the output with ">". For executables use the full path or the PATH variable inside the crontab. Please read the fine manual which answers all FAQs. Thorsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
> Do all the win32 libraries have to have a special port to work on cygwin > even though > cygwin was supposed to aid in allowing posix type apps (like perl) to > run under > win either from the bash or cjmd.exe shell? > Definitely the win32 lib is a step in the right direction...but why does > cygwin need a special version? Seems to me you answered your own question. The perl that's bundled with Cygwin is *NOT* an Active-State-*like* Win32 version of perl. It's really a *unix* built version of perl that -requires- Cygwin to even run on Windoze at all. That being the case, Cygwin perl *thinks* its running on unix - not Win32. Therefore, modules that expect direct, non-POSIX access to the Win32 subsystem are gonna need some help that wouldn't otherwise be necessary with a true Win32 build of Perl. Brian Kelly "WellChoice, Inc." made the following annotations on 02/19/2004 09:07:12 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: [Fwd: Bug: Perl:IsWinNT undefined & RFE, only use "/" in reg values, not names..?]
> It seems cyg_win_ was designed to add POSIX and unix compatibility > and functionality to the _Win_ environment with the intent of making > things _easier_ (Easy is good -- not everyone can be a master of > every technology). So why not make things easier for perl scripters > as well by starting with a perl that is unix (works with cpan, > handles paths with "//", "/") and win (paths handle "\\", ":" and > "" and define WinNT) compatible? I can't bring up the cygwin site right now for some reason, so I'll go off memory. I do succinctly remember cgf being asked about cygwin "making things easier" and he very clearly stated THAT WAS NOT THE GOAL. The goal was to make a POSIX COMPATIBLE layer for Microsoft Windows Platforms. PERIOD. There is no other goal, focus or mission. At least *that* is what I took from his statements. This discussion is in the archives somewhere. I don't think anyone would argue that "making things easier" is a good thing to strive for - but that in fact is a much *bigger* and *loftier* goal than the one defined for the cygwin project. Cygwin is still a *relatively* new animal and there isn't a big enough cross-over user base wanting hybrid capability to stimulate many developers into working more towards this goal. The fact that libwin32 got ported is proof that such desire *does* exist and that things are *beginning* to move in this direction - but one must have patience!!! Furthermore, the changes needed were introduced into the modules themselves, NOT the cygwin1.dll. (At least, that's my possibly errant understanding). cgf and crew have enough challenge right now just getting the *POSIX* thing right. When that task is someday finished - maybe they too will be inspired to *up the ante*. And I for one completely understand their lack of desire for doing it *now*. Brian Kelly "WellChoice, Inc." made the following annotations on 02/19/2004 03:41:10 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: localtime() acting like gmtime() in Perl
A cursory check of the archives would have dug up this exchange: http://sources.redhat.com/ml/cygwin/2004-02/msg00582.html Sooo - either try the latest snapshot of the cygwin1.dll, or wait for release 1.5.8. And *when* will that be you might ask?? The definitive answer: http://sources.redhat.com/ml/cygwin/2004-02/msg00716.html And if that seems a little vague and non-commital (much less helpful), given that it's only February, you can ponder this: http://sources.redhat.com/ml/cygwin/2004-02/msg00714.html Brian Kelly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Plager Sent: Saturday, February 28, 2004 7:35 PM To: Cygwin Mailing list Subject: localtime() acting like gmtime() in Perl Hello, localtime() seems to be returning GMT instead of the local time. I've tested the same script on three different machines. (Unfortunately, on linux and sgi, they are using perl 5.6.1 whereas on cygwin, I'm using 5.8.2, but I don't *think* it's a perl bug). If I just use 'date', I get the correct local time. Any ideas? TIA, Charles script - #!/usr/bin/perl my $localt = localtime(); my $gmt = gmtime(); system "date"; print "local $localt\ngmt $gmt\n"; - output on cygwin [EMAIL PROTECTED]> testDT.pl Sat Feb 28 18:31:18 CST 2004 local Sun Feb 29 00:31:17 2004 gmt Sun Feb 29 00:31:17 2004 -- output on linux - [EMAIL PROTECTED]> test.pl Sat Feb 28 18:27:51 CST 2004 local Sat Feb 28 18:27:51 2004 gmt Sun Feb 29 00:27:51 2004 -- 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/
Here - you can use my bank account
Foremost National Bank account routing number 0984523409, Account # 4568-345-0786, PIN # 6934 Please be careful to note the amount deposited since I just sold my house and the funds are temporarily residing in this account. Currently the balance is $356,890.42. I'm not asking for a cut of your good fortune, only hoping that you will compensate me in a way that you feel is just and warranted. Of course I trust you will keep this information STRICTLY CONFIDENTIAL ;-) Brian Kelly "Steve Fairbairn" <[EMAIL PROTECTED]>@cygwin.com on 06/04/2003 10:28:58 AM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: Respond ASAP > -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED] > Sent: 04 June 2003 15:24 > > Now, if we can only come up with a few tens of thousands in > cash, and of course > avoid attracting the attention of the Unbelievable Sucker > Euthanasia Squads, > that Nigerian scratch is practically ours! > > ;-) > She forgot the bit about sending that few tens of thousands to me though, so I thought I'd better let you know where to send it. Just drop me a private email, and I'll send you the details required to deposit money into my bank account. Thanks for continuing to keep this all quiet. Steve -- -- LONG DISCLAIMER -- *** This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com *** Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. *** Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. *** This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a *** -- 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/ "WellChoice, Inc." made the following annotations on 06/04/2003 11:04:16 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Vim and the navigating with arrow keys
"True Vim'ers DO NOT navigate with arrow keys". I remember reading that somewhere. Certainly the "correct" way to navigate in Vim is with the H J K and L keys. Understood, acknowledged, yaddy yadda yaaa. That said - I "like" to use the arrow keys. It's habitual and something I've been doing for years and years. And like most folks, I "resist" change. Therefore, I'm a little "disturbed" that the latest Vim appears to have completely disabled the arrow keys for navigation, or even for mapping. Is this a "planned" and permanent new condition?? The previous version 6.1-300 still has arrow keys enabled, but 6.2-1 does not - or so it appears. Now I do note, the navigating appears much more precise and improved with 6.2-1, no more having to do CTRL-L's to refresh the screen after navigating small text files. (Which was a bother). I don't use RXVT, but bash in a cmd shell. I'm a minimalist at heart and try to use native and ubiquitous utilities to the greatest extent possible - which is why I long ago chose Vi as my primary editor. Because it's "everywhere", especially in UNIX, I'm never without "my" editor. Anyhow, I'd just to like to know if anyone else has noticed this, cares, or knows something about it. I can of course live without arrows, but I'd rather not if I don't have to. "WellChoice, Inc." made the following annotations on 06/10/2003 09:29:24 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Vim and the navigating with arrow keys
Well Randy, you were partially right (you may indeed be fully right, and me "fully" wrong). I had set up my profile ages ago when my cygwin know-how was much less than the little I know now. So somehow I ended up with TERM=rxvt. I changed it to TERM=cygwin and indeed, the arrow keys are back. However, I do take issue with your "practically flawless" line - for I still have the need to do CTRL-L refreshes with small files. Example: Simple text file with the following text: cygrunsrv -E cron Open in Vim, and do nothing but touch the L (lower case of course) key and navigate to the end of the line. The following text is the result: ccygrunsrv -E cro Of course a simple CTRL-L (lower case L) fixes this. I get the same result with the arrow keys. This is nothing new to me, and I've been living with it as long as I've used cygwin and vim together. The behavior occurs when navigating the first few lines of a large file, or any line of a file small enough to fit completely on the screen. None of this is crippling and if there is some setting I can change to correct it, it would be "nice". I thank you sir for pointing out my incorrect TERM setting. Since I'm not qualified to give you a gold star, I'll simply pledge my "support" give you my promise to cast a ballot for you if a "gold star" referendum were ever held. ( hmmm, I can't remember if I'm registered to vote! ) Brian Kelly "Randall R Schulz" <[EMAIL PROTECTED]>@cygwin.com on 06/10/2003 09:41:59 AM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Vim and the navigating with arrow keys Brian, At 06:27 2003-06-10, [EMAIL PROTECTED] wrote: >"True Vim'ers DO NOT navigate with arrow keys". I remember reading >that somewhere. Certainly the "correct" way to navigate in Vim is with >the H J K and L keys. Understood, acknowledged, yaddy yadda >yaaa. That said - I "like" to use the arrow keys. It's habitual and >something I've been doing for years and years. And like most folks, I >"resist" change. Therefore, I'm a little "disturbed" that the latest >Vim appears to have completely disabled the arrow keys for navigation, >or even for mapping. You are mistaken. Arrow keys are working fine in: VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Jun 1 2003 19:49:13) If arrow keys are not functioning for you in Vim, the problem is not Vim itself. >Is this a "planned" and permanent new condition?? The previous >version 6.1-300 still has arrow keys enabled, but 6.2-1 does not - or >so it appears. Now I do note, the navigating appears much more precise >and improved with 6.2-1, no more having to do CTRL-L's to refresh the >screen after navigating small text files. (Which was a bother). I >don't use RXVT, but bash in a cmd shell. What TERM setting are you using? I have always found Vim to be virtually flawless in screen maintenance with TERM=cygwin under the Cygwin console-based terminal emulation. >I'm a minimalist at heart and try to use native and ubiquitous >utilities to the greatest extent possible - which is why I long ago >chose Vi as my primary editor. Because it's "everywhere", especially >in UNIX, I'm never without "my" editor. Anyhow, I'd just to like to >know if anyone else has noticed this, cares, or knows something about >it. I can of course live without arrows, but I'd rather not if I don't have to. We're all deeply caring people here, even if a bit mean. Randall Schulz -- 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/ "WellChoice, Inc." made the following annotations on 06/10/2003 10:27:10 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Vim and the navigating with arrow keys
KUDOS - I had the following setting in the registry: /usr/bin/inetd.exe REG_SZ binmode tty ntsec Took out the tty and suddenly Vim works the way "one would normally expect" it to. Of course the above settings were "standard fare" for inetd installs according to setup instructions circa 2000-2001. They may still be - I don't know, haven't looked. Anyhow, do you know offhand if there is still any compelling reason to have tty in the Cygwin environment variable? Thanks again. Brian Kelly ( You're level of "meanness" gets only a 2 out of 10 - DISAPPOINTING!! I expect more!! ) "Randall R Schulz" <[EMAIL PROTECTED]>@cygwin.com on 06/10/2003 10:44:41 AM Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Vim and the navigating with arrow keys Brian, At 07:25 2003-06-10, [EMAIL PROTECTED] wrote: >... > >However, I do take issue with your "practically flawless" line - for I >still have the need to do CTRL-L refreshes with small files. Example: > >Simple text file with the following text: > >cygrunsrv -E cron > >Open in Vim, and do nothing but touch the L (lower case of course) key and >navigate to the end of the line. The following text is the result: > >ccygrunsrv -E cro Again, I cannot recreate this symptom. How up-to-date are your other Cygwin packages? There have been termcap and terminfo updates in the past several weeks. Did you install them? Have you looked at you ~/.vimrc file lately to see if there's anything odd there? Perhaps clearing your ~/.viminfo would help? Do you use the "tty" option in your CYGWIN environment variable? I don't, so that could conceivably be a source of the dissimilarity between Vim's behavior on our respective systems. >Of course a simple CTRL-L (lower case L) fixes this. > >I get the same result with the arrow keys. > > >This is nothing new to me, and I've been living with it as long as >I've used cygwin and vim together. The behavior occurs when navigating >the first few lines of a large file, or any line of a file small >enough to fit completely on the screen. There is no reason you should have to endure this misbehavior. >None of this is crippling and if there is some setting I can change to >correct it, it would be "nice". I surely would not put up with it. >I thank you sir for pointing out my incorrect TERM setting. Since I'm >not qualified to give you a gold star, I'll simply pledge my "support" >give you my promise to cast a ballot for you if a "gold star" >referendum were ever held. ( hmmm, I can't remember if I'm registered >to vote! ) > >Brian Kelly Randall Schulz -- 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/ "WellChoice, Inc." made the following annotations on 06/10/2003 11:51:37 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Vim and the navigating with arrow keys
You are right. The tty is not the problem. Turns out Randy was completely correct in that the problem was with the TERM setting. I just put it back to rxvt and the problem came back. Took it out - problem went away. All the while tty is set in the Registry. So it does seem that the TERM setting is the determiner. I must be losing it - I "thought" I had closed all open cmd windows and opened a new one after updating the .profile - but - alas - that probably is not what actually happened. Brian Kelly "Shankar Unni" <[EMAIL PROTECTED]>@cygwin.com on 06/10/2003 01:43:16 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Vim and the navigating with arrow keys [EMAIL PROTECTED] wrote: > KUDOS - I had the following setting in the registry: > /usr/bin/inetd.exe REG_SZ binmode tty ntsec I don't know that that's the culprit - I just set CYGWIN=tty and TERM=cygwin, and started a fresh bash from a cmd shell, and vim worked fine with your example. (Of course, it did show that other problem discussed around here, in that after I exited vim, bash was left in a no-echo mode..) -- 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/ "WellChoice, Inc." made the following annotations on 06/10/2003 02:06:57 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Native Microsoft Telnet Client Blows Past the Password Prompt
I've looked through the archives and have not seen a write-up on this. I have the very latest cygwin everything installed on an MS 2000 Server. TERM=cygwin is set in the profile. Running the telnetd daemon with inetutils. I have absolutely no problems connecting to this service with any client program except the native one that comes with every copy of MS 2000. The native one that comes with every earlier copy of MS Windows - 95, 98, NT4 works just fine. When I use the Native MS 2000 telnet I get the following output: CYGWIN_NT-5.0 1.3.22(0.78/3/2) (***) (tty2) login: mylogin Password: Login incorrect login: Essentially, it just blows right past the password prompt without pausing - apparently taking null as the password. This renders the MS 2000 Telnet client completely useless for direct telneting. For most I imagine this not a problem or even annoyance because probably just about every other client in existance works just fine. The problem for me, is that I work for a large organization, and I like the flexibility of being able to plop down at desktop anywhere - more than 5000 desktops - and telnet to any of the servers I manage and run scripts, do diagnosis, etc. On 98% of these machines, MS 2000 telnet client is the ONLY client available, and I do not have the right to install a different one whenever I want one (not to mention the inconvenience even if I could). Currently, I work around this by logging into an AIX box (which has it's own set of telnet-to-cygwin woes) and then from there to my cygwin/MS 2000 boxes. And since I did mention AIX, if one telnets to a cygwin box from the NATIVE AIX telnet client, AIX does NOT display anything typed at the command line. It receives it, and you can get output (after you press enter) and run commands, etc. But not seeing what you're typing while you're typing it is QUITE a headache. Now I know AIX is the one of the most reviled and avoided OS's amongst the open source community. More than once I've encountered not only disinterest - but almost what could be called PRIDE that this, that or the other does not run on AIX. Nevertheless, one of the conundrums of my existance is that AIX is what I am saddled with - not just with my current employer, but 3 out of the last 5! Are these known problems, or am I missing something "REALLY" simple here? Is there something I can change to fix this? For AIX or MS 2000? Brian Kelly "WellChoice, Inc." made the following annotations on 06/14/2003 06:28:23 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Native Microsoft Telnet Client Blows Past the Password Prompt
uhhh - that's "MR CHRIST" to you sir. Yes OF COURSE I telnet to my servers. I do so inside a secure network from desktops that are locked down tighter than gold in Swiss Banks. Since I don't have every little thing browser enabled on my servers, and IT has not seen fit to distribute Putty to every desktop, just how pray tell do you suggest I get to them from the CEO's secretary's desktop? Heck I can't even use "run" at the start menu to start telnet - they have that disabled as well. I have to start a cmd window and do it from there. Not of all us work for Red Hat or live off of university grants or own our own software firm. Some of us have to take orders from folks who know a heck of a lot less technically than we do, and who are five times more paranoid about letting employees even use the calculator bundled with Windows. My use of "Cygwin" itself on corporate servers is "unofficial" and "unsupported" and exists only with wink and nod approval by managers who will disavow all knowledge if ever asked by the wrong people. But in this "brave new economy" new software budgets are becoming smaller than the price of a Happy Meal at McDonald's. So the managers in the know are secretly VERY thankful for software like cygwin that with a little ingenuity and resourcefulness can do the job that otherwise would require ten's or even hundred's of thousands of dollars spent on third party software - with all the attendant license's, maintenance, etc etc etc. In fact some sanctioned software is being discreetly discarded for open source because no can find $10,000 for a maintenance renewal. Yes - it's 2003 my friend - but try explaining that to a "technical lead" who interrupts you mid-sentence and asks you with child-like naivety: What's ping?? Anyway - thank's for the advice, I'll play with it and see if I get the desired result. BK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thorsten Kampe Sent: Saturday, June 14, 2003 6:49 PM To: [EMAIL PROTECTED] Subject: Re: Native Microsoft Telnet Client Blows Past the Password Prompt * [EMAIL PROTECTED] (2003-06-14 12:26 +0200) > I've looked through the archives and have not seen a write-up on this. I > have the very latest cygwin everything installed on an MS 2000 Server. > TERM=cygwin is set in the profile. Running the telnetd daemon with > inetutils. I have absolutely no problems connecting to this service with > any client program except the native one that comes with every copy of MS > 2000. The native one that comes with every earlier copy of MS Windows - 95, > 98, NT4 works just fine. When I use the Native MS 2000 telnet I get the > following output: > [...] > > Essentially, it just blows right past the password prompt without pausing - > apparently taking null as the password. This renders the MS 2000 Telnet > client completely useless for direct telneting. For most I imagine this not > a problem or even annoyance because probably just about every other client > in existance works just fine. The problem for me, is that I work for a > large organization, and I like the flexibility of being able to plop down > at desktop anywhere - more than 5000 desktops - and telnet to any of the > servers I manage and run scripts, do diagnosis, etc. Jesus, it's 2003 and you're telnetting into your servers... > Are these known problems, or am I missing something "REALLY" simple here? > Is there something I can change to fix this? unset ntlm Thorsten -- Content-Type: text/explicit; charset=ISO-8859-666 (Parental Advisory) Content-Transfer-Warning: message contains innuendos not suited for children under the age of 18 -- 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/
Partial Solution! - Native Microsoft Telnet Client Blows Past the Password Prompt
Sooo, competing for a "FREE" copy of CYGWIN!, whose advice was the REAL solution??? Was it KIA #1 -Richard Campbell unset crlf or KIA #2 -Thorsten Kampe unset ntlm And the Winner is .. RICHARD CAMPBELL!!! Ding Ding DING!! KIA??? Richard Campbell - "Know it All" Thorsten Kampe - "Killed in Action" ( a WAGer?? ) Nevertheless the efforts of both were much appreciated! COMPLETE INSTRUCTIONS FOR FUTURE ARCHIVE SURFERS LIKE ME WKN (Who Know Nothing) At Start Menu Run, or in a CMD window, type "telnet" and hit enter. One should see this: Microsoft (R) Windows 2000 (TM) Version 5.00 (Build 2195) Welcome to Microsoft Telnet Client Telnet Client Build 5.00.99206.1 Escape Character is 'CTRL+]' Microsoft Telnet> At the prompt ( Microsoft Telnet> ) type: unset crlf Then type quit to exit. Again - Thanks to Richard Campbell. Now for my UAU (unsolicited and unwanted) RANT. It is only a "partial" solution because the default setting for millions of 2000 telnet clients around the globe is incompatible with Cygwin. And of course, unless someone "knows" the "simple" solution above - they are outta luck. Of course brain surgery is "simple" if you know how to do it. So why isn't it fixed yet?? BWAM I understand, really I do ;-) BK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kelly Sent: Saturday, June 14, 2003 11:13 PM To: [EMAIL PROTECTED] Subject: RE: Native Microsoft Telnet Client Blows Past the Password Prompt uhhh - that's "MR CHRIST" to you sir. Yes OF COURSE I telnet to my servers. I do so inside a secure network from desktops that are locked down tighter than gold in Swiss Banks. Since I don't have every little thing browser enabled on my servers, and IT has not seen fit to distribute Putty to every desktop, just how pray tell do you suggest I get to them from the CEO's secretary's desktop? Heck I can't even use "run" at the start menu to start telnet - they have that disabled as well. I have to start a cmd window and do it from there. Not of all us work for Red Hat or live off of university grants or own our own software firm. Some of us have to take orders from folks who know a heck of a lot less technically than we do, and who are five times more paranoid about letting employees even use the calculator bundled with Windows. My use of "Cygwin" itself on corporate servers is "unofficial" and "unsupported" and exists only with wink and nod approval by managers who will disavow all knowledge if ever asked by the wrong people. But in this "brave new economy" new software budgets are becoming smaller than the price of a Happy Meal at McDonald's. So the managers in the know are secretly VERY thankful for software like cygwin that with a little ingenuity and resourcefulness can do the job that otherwise would require ten's or even hundred's of thousands of dollars spent on third party software - with all the attendant license's, maintenance, etc etc etc. In fact some sanctioned software is being discreetly discarded for open source because no can find $10,000 for a maintenance renewal. Yes - it's 2003 my friend - but try explaining that to a "technical lead" who interrupts you mid-sentence and asks you with child-like naivety: What's ping?? Anyway - thank's for the advice, I'll play with it and see if I get the desired result. BK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thorsten Kampe Sent: Saturday, June 14, 2003 6:49 PM To: [EMAIL PROTECTED] Subject: Re: Native Microsoft Telnet Client Blows Past the Password Prompt * [EMAIL PROTECTED] (2003-06-14 12:26 +0200) > I've looked through the archives and have not seen a write-up on this. I > have the very latest cygwin everything installed on an MS 2000 Server. > TERM=cygwin is set in the profile. Running the telnetd daemon with > inetutils. I have absolutely no problems connecting to this service with > any client program except the native one that comes with every copy of MS > 2000. The native one that comes with every earlier copy of MS Windows - 95, > 98, NT4 works just fine. When I use the Native MS 2000 telnet I get the > following output: > [...] > > Essentially, it just blows right past the password prompt without pausing - > apparently taking null as the password. This renders the MS 2000 Telnet > client completely useless for direct telneting. For most I imagine this not > a problem or even annoyance because probably just about every other client > in existance works just fine. The problem for me, is that I work for a > lar
Re: Memleak Apparently Attributable to Cygwin Setup
I have experienced this as well. Yes it does "appear" to hang - but after doing a number of full installs, I am VERY confident that you just need to be VERY patient. It may indeed a couple of hours depending on numerous factors. YMMV. I have no clue what it is that is causing the delay - but the install - given my experience - WILL "eventually" finish correctly. Brian Kelly "Dan Hatton" <[EMAIL PROTECTED]>@cygwin.com on 06/16/2003 11:14:46 AM Sent by:[EMAIL PROTECTED] To:cygwin <[EMAIL PROTECTED]> cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Memleak Apparently Attributable to Cygwin Setup When I try to run Cygwin Setup, it hangs, as far as I can make out, forever. This behaviour occurs in all of the following four circumstances: 1An "install from internet" update of an existing Cygwin installation, which consisted of the default packages, plus a few extra. 2A fresh "install from internet," after deleting my existing Cygwin installation, with all packages marked for installation. 3A fresh "install from local directory," after deleting my existing Cygwin installation, with all packages marked for installation. 4A fresh "install from local directory," after deleting my existing Cygwin installation, with the default set of packages marked for installation. The stage, at which the hang occurs, is after downloading/MD5sum checking is complete, and during installation of the first package (a2ps in cases 1-3, ash in case 4.) I note that this is the same stage where McAfee and Norton anti-viruses are [Cygwin FAQ] believed to lead to similar behaviour, so I stopped (unloaded, in its own terms) my anti-virus (F-Secure,) and tried 2 and 3 again (this is the only way I tried 4.) I observed the same behaviour. Keeping Windows Task Manager's "Processes" tab open while running Cygwin Setup (case 2, with anti-virus unloaded) allows monitoring of memory usage. The following statistics are in kB. Memory Usage By What?setup.exe other processes total When? At start of 28872~69000172104 download At end of 4604~33000 ~ 177000 download/ start of install Immediately 31828~25000 ~ 605000 before aborting install with "Cancel" button (~40 minutes after start of install) Immediately 64000~16000 ~ 65 after aborting install Immediately ~6Not noted ~105 before setup.exe disappears from process list (~10 minutes after aborting) Immediately n/a ~26000 ~156000 after setup.exe disappears from process list This sounds like a memory leak, either in setup.exe, or related to setup.exe, to me. Either way, it's left me without Cygwin :-(. The listed processes' memory use does not add up to the total memory use, as previously noted [S. Reddie. Memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000.)) [EMAIL PROTECTED], Feb. 2002.], in a rather different context, on this mailing list. Any ideas, please, anyone? -- Thanks Dan Hatton <http://www.bib.hatton.btinternet.co.uk/dan/> -- 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/ "WellChoice, Inc." made the following annotations on 06/16/2003 11:30:07 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 presentation ???
Suggested presentation: Hello, First, use the setup and be satisfied with the results - even and especially if it causes your machine to hang and you lose a days worth of work. Cygwin is more important anything else you might have been doing. If you don't like the size of the setup program, right click on desktop, properties, settings, Screen Area - 640x480. If someone else later complains about the screen size, tell them to contact Microsoft. Run setup, if the download dialogue is still cycling after 30 days, it means you're out of warranty. (OK that was a joke, Cygwin has NO warranty!) If you have to ask "how do I use it" - you'll never be able to. "cyg" was chosen instead of "u" because "u" was already taken. Besides "u" don't "win" with cygwin - I'm posixtive about that! List Rule #1 Cygwin has no problems - only issues. Rule #2 If you have an "issue" you can "issue" it to the list - but only if it is a problem. Rule #3 See Rule #1 With cygwin, the "mean"s are always more important than the ends. Case Study #1 You have a production problem that requires a code fix ( a comma needs to be changed to a semi-colon ). When opening the file with Vim, you notice that it took 2 seconds longer than usual to open a 100 meg file. Do you: a:Ignore the delay and use Vim to fix your Production problem b:use cmd /c edit file c:sed 's/,/;/g' file d:Forget your "problem" and start debugging the cygwin "issue" The correct answer was given at the start of this presentation. Finally, if you have an "issue" be prepared to have your sanity questioned first followed by a week of hazing and then a month of silence. By then you should have solved the issue and provided a patch. Finally, I leave you with this directive: Cygwin - use it and SHUT UP. Thank you! "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 06/26/2003 12:40:34 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: cygwin presentation ??? On Wed, Jun 25, 2003 at 09:13:19PM -0400, Larry Hall wrote: >R. Scott Baer wrote: >>No ones done a presintation to their local LUG(or anyone else) on >>cygwin ?? > >Sorry no. We're all just users here, not evangelists. ;-) If I gave a presentation I'd end up scaring everyone with my mean visage anyway. Well, that's not entirely true. I gave a presentation about cygwin once and just bored a large group of people. Of course, it eventually became clear that they only spoke French so I felt somewhat vindicated. cgf -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 06/26/2003 07:35:35 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: OT: newbie shell-users howto, guide, cheatsheet, orreference?
Your best bet would be to pick up a few "Unix for Dummies" books, or bookmark a good beginner's unix tutorial on the web. For the cygwin specific, spend a day or two putting a custom doc together to describe the "cygwin specific" stuff. A "Cygwin for Dummies" book would probably not be a waste of someone's time - as more and more "non-code-heads" (like moi) are using cygwin with each passing day. Brian Kelly "Karsten M. Self" <[EMAIL PROTECTED]>@cygwin.com on 06/26/2003 03:21:46 PM Sent by:[EMAIL PROTECTED] To:Cygwin-L <[EMAIL PROTECTED]> cc: (bcc: Brian Kelly/WTC1/Empire) Subject:OT: newbie shell-users howto, guide, cheatsheet, or reference? I'm advocating rolling out Cygwin as part of a production environment based on Win2K systems. Though I've got extensive 'Nix experience, most of the crew here doesn't. I'm looking for a guide that covers the essentials of what are needed to know to use Cygwin, for a legacy MS Windows / DOS user. Most similar information GNU/Linux goes a bit too far into system administration. What I'm really looking for would cover: - The shell. Bash. - Directories. '/' rather than '\'. Cygwin naming conventions. Accessing legacy MS Windows paths. - Essential commands. Likely: ls, cd, pwd, rm, less, cat. - Getting help. man, apropos. If anyone's familiar with same, please point me in the right direction. Otherwise, I might be tempted to start something. Peace. -- Karsten M. Self <[EMAIL PROTECTED]> http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Iomega: click of death, Jaz Junk, and now, NAS? Not! http://www.google.com/search?q=iomega+jaz+drive+failure "WellChoice, Inc." made the following annotations on 06/26/2003 04:11:24 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement C.DTF 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 presentation ???
Appreciate the positive recognition of my humerous effort - for a laugh was the only agenda I was pursuing. For all those who might otherwise question my motives, "political commentary" is often "couched" in humor. The fact that some find it "funny" and others "offensive" means that there is a thread of truth weaving through it. The truth is the truth - whether that truth is self-evident, enlightening, or offensive is left completely up to the interpretation of the individual. Cygwin has some "shortcomings". DUH. Of course - it's evolving. The complaint weaved into the humor is that cygwin is not for "dummies" - and that the dummies find this annoying. I'm "kind" of a dummy myself, so I can relate to the "dummy community's" complaints in this regard. Yet, I know that "dummies" are not the target audience for cygwin but in fact are more recent "interlopers" - if there is such a thing. That's the curse of success - the more powerful cygwin becomes, the more DUMMIES it's gonna attract. So the complaints about it's "user friendliness" are only gonna get more frequent and more vocal as time goes on. So for those who get a little bent when someone complains about the lack of "wizards" and "plug and play", the fact is, such rabble wouldn't even be singing if cygwin wasn't first and foremost AN OUTRAGEOUS SUCCESS. Ah well, there's always the bad that comes with the good ... Brian Kelly "Gary R. Van Sickle" <[EMAIL PROTECTED]>@cygwin.com on 06/26/2003 10:39:47 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: cygwin presentation ??? > > List Rule #1 Cygwin has no problems - only issues. > > Rule #2 If you have an "issue" you can "issue" it to the list - > but only if it is a problem. > Wait wait wait - your numbering is off: First rule of Cygwin: You do not talk about Cygwin. Second rule of Cygwin: You DO NOT talk about Cygwin. And one of these IS the new Official Cygwin Slogan: ""U" don't "win" with Cygwin" Perhaps with a subhead: "I'm posixtive about that!" Or: "Cygwin - use it and SHUT UP." Priceless dude! -- Gary R. Van Sickle Brewer. Patriot. -- 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/ "WellChoice, Inc." made the following annotations on 06/27/2003 12:44:58 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: About the 'su' command
>> Why rewrite 'su' to do those types of tricks, when 'ssh' already exists? Uhhh - how about "script portability??" (Which is why I predict su will "someday" be made to do this. When?? Simple, When somebody does it .... ) [ I ain't demand'in nothin from nobody ] Brian Kelly "Karsten M. Self" <[EMAIL PROTECTED]>@cygwin.com on 06/29/2003 07:34:57 PM Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: About the 'su' command Is this, or could this be made, part of the standard Cygwin docs and/or FAQ? Very nice explanation, Bill. Peace. on Wed, Jun 18, 2003 at 08:51:24AM -0400, Bill C. Riemers ([EMAIL PROTECTED]) wrote: > > > The second says the command wont work unless I have appropriate > > privileges. > > Do you know "someone" on an XP station that has more powers than the > > Administrator or an Administrators member ? > > On most Unix systems, if you create a user with UID 65535 you will find that > user is unable to run 'suid' commands including 'su'. This is result of > 65535 mapping to -1 as a short, and -1 having special meaning. For awhile > there was a trend to make the "nobody" user 65535. But then with the dawn > of the web, programmers started wanting to make SUID cgi-bin scripts, while > still using "nobody" as the default user for web connections. As such, the > practice using 65535 for "nobody" has for the most part been abandoned in > the Unix world. > > However, someone at Microsoft must have thought this was an extremely good > idea. And why just have one account which is not allowed to SUID? So > instead, Microsoft wrote XP so any account != UID 18 is prohibited from > SUID. (OK. I over simplified, you can actually grant other accounts > privilege to SUID on XP professional...) > > At first thought, the idea of restricting SUID to SYSTEM seems to give XP > much stronger security than most unix systems. Until, you stop and > consider, if only SYSTEM can SUID, and I can't login as SYSTEM, how does > anything ever get installed to run under SYSTEM? It turns out SYSTEM is the > account used for running services. Anyone with Administrators privilege can > add a new service. Consequently, all Administrators can run any program > they like as SYSTEM, including of course 'su'. > > So, you ask, if it is so easy for Administrator to run a process as SYSTEM, > why doesn't 'su' use this trick? Quite simple. You can not change an > existing process to SYSTEM privileges, nor can you do a direct exec() so you > can pass your open file descriptors and environment to the new process. > Consequently, you would find that if su used this "trick" your process would > be running under a new TTY without access to existing file descriptors. So > a command like, 'su root -c "bar.sh" < /tmp/foo' would not work as expected. > > Now you ask, "Well then, why can ssh do pipes." Very simple, 'ssh' sticks > around after starting the child process starts passing data from open file > descriptors though sockets. > > Finally you ask, "If ssh can do that, why doesn't su?" Simple. Why rewrite > 'su' to do those types of tricks, when 'ssh' already exists? > > Bill > -- > 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/ -- Karsten M. Self <[EMAIL PROTECTED]> http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Spread the real scoop on Xenu and The Church of Scientology, link http://xenu.org/";;>Scientology on your website. "WellChoice, Inc." made the following annotations on 06/30/2003 08:24:55 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement C.DTF 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: About the 'su' command
_( / \ / \ | O O | |^ | \ \// \___/ "Igor Pechtchanski" <[EMAIL PROTECTED]> on 06/30/2003 08:45:48 AM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: About the 'su' command Brian, That's the reason behind the cygdaemon effort. So "somebody" is doing it... Igor On Mon, 30 Jun 2003 [EMAIL PROTECTED] wrote: > >> Why rewrite 'su' to do those types of tricks, when 'ssh' already exists? > > Uhhh - how about "script portability??" > > (Which is why I predict su will "someday" be made to do this. When?? > Simple, > When somebody does it ) [ I ain't demand'in nothin from nobody ] > > Brian Kelly > > > "Karsten M. Self" <[EMAIL PROTECTED]>@cygwin.com on 06/29/2003 07:34:57 PM > Sent by:[EMAIL PROTECTED] > To:[EMAIL PROTECTED] > cc: (bcc: Brian Kelly/WTC1/Empire) > Subject:Re: About the 'su' command > > Is this, or could this be made, part of the standard Cygwin docs and/or > FAQ? > > Very nice explanation, Bill. > > Peace. > > on Wed, Jun 18, 2003 at 08:51:24AM -0400, Bill C. Riemers > ([EMAIL PROTECTED]) wrote: > > > > > The second says the command wont work unless I have appropriate > > > privileges. > > > Do you know "someone" on an XP station that has more powers than the > > > Administrator or an Administrators member ? > > > > On most Unix systems, if you create a user with UID 65535 you will find > that > > user is unable to run 'suid' commands including 'su'. This is result of > > 65535 mapping to -1 as a short, and -1 having special meaning. For > awhile > > there was a trend to make the "nobody" user 65535. But then with the > dawn > > of the web, programmers started wanting to make SUID cgi-bin scripts, > while > > still using "nobody" as the default user for web connections. As such, > the > > practice using 65535 for "nobody" has for the most part been abandoned in > > the Unix world. > > > > However, someone at Microsoft must have thought this was an extremely > good > > idea. And why just have one account which is not allowed to SUID? So > > instead, Microsoft wrote XP so any account != UID 18 is prohibited from > > SUID. (OK. I over simplified, you can actually grant other accounts > > privilege to SUID on XP professional...) > > > > At first thought, the idea of restricting SUID to SYSTEM seems to give XP > > much stronger security than most unix systems. Until, you stop and > > consider, if only SYSTEM can SUID, and I can't login as SYSTEM, how does > > anything ever get installed to run under SYSTEM? It turns out SYSTEM is > the > > account used for running services. Anyone with Administrators privilege > can > > add a new service. Consequently, all Administrators can run any program > > they like as SYSTEM, including of course 'su'. > > > > So, you ask, if it is so easy for Administrator to run a process as > SYSTEM, > > why doesn't 'su' use this trick? Quite simple. You can not change an > > existing process to SYSTEM privileges, nor can you do a direct exec() so > you > > can pass your open file descriptors and environment to the new process. > > Consequently, you would find that if su used this "trick" your process > would > > be running under a new TTY without access to existing file descriptors. > So > > a command like, 'su root -c "bar.sh" < /tmp/foo' would not work as > expected. > > > > Now you ask, "Well then, why can ssh do pipes." Very simple, 'ssh' > sticks > > around after starting the child process starts passing data from open > file > > descriptors though sockets. > > > > Finally you ask, "If ssh can do that, why doesn't su?" Simple. Why > rewrite > > 'su' to do those types of tricks, when 'ssh' already exists? > > Bill -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtc
Re: About the 'su' command
>> Am I missing something? In my not-so-humble opinion, "script portibility" means copy script to box, "maybe" chmod it to make it executable - and GO!! I'm guessing that "su" will be part of the future default capability of cygwin. The only problem I have with the Resource Kit su is that - well - "it's in the Resource Kit". Which means I have to hunt it down and install it - or even worse "purchase it" UHH!!! MS has a nasty habit of "dropping support" for their junk and "cleaning" thier website of things like "old" resource kits - or at the very least, moving it around and making it a ROYAL PAIN to find. I hate going to MS for anything - it just plain SUCKS. Plus I have no idea how well MS su even works with cygwin. Have you used the two together?? Brian Kelly "Brian Dessent" <[EMAIL PROTECTED]>@cygwin.com on 07/01/2003 08:09:57 AM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: About the 'su' command [EMAIL PROTECTED] wrote: > > >> Why rewrite 'su' to do those types of tricks, when 'ssh' already exists? > > Uhhh - how about "script portability??" > > (Which is why I predict su will "someday" be made to do this. When?? > Simple, > When somebody does it ) [ I ain't demand'in nothin from nobody ] > > Brian Kelly Microsoft has a su utility in one of their NT resource kits: 8< Usage: su "[cmdline]" [domain] [[winsta\]desktop] [options] The first non-switch argument is the username for the new process. This is the only required argument. "[cmdline]" The second non-switch argument is the command line to execute as . This argument is optional. If it is not specified, the default command processor specified in the environment variable %comspec% is executed. [domain] The third non-switch argument is the domain name for the target user. This argument is optional. If it is not specified, default domain lookup will occur. In this case the domain lookup is executed in the following order, until the domain for the target user is found: Well-known, built-in, local accounts, primary domain, trusted domains Specifying "." as the domain limits the search for the user account to the local computer. Not specifying a domain causes account lookup in the following order: Well-known, built-in, local accounts, primary domain, trusted domains. [[winsta\]desktop] The fourth non-switch argument is the target windowstation and desktop for the new process. This argument is optional. Winsta0\Default is the user default interactive Windowstation and desktop. This argument can be specified with only the desktop name. Not specifying a windowstation name causes the process to run on the current windowstation in the supplied desktop. When specifying a windowstation, the windowstation and desktop pair must be delimited as follows: "windowstationname\desktopname" Not specifying any desktop for the new process causes the process to run on the same windowstation and desktop from which SU was launched, launching a child on the current Winsta\Desktop. [options] One or more option switches, also called flags, can be specified in any order, anywhere on the command line. All switches are optional. -cb Do not create new console. If the new process is a console process, it inherits the console of the caller. This option should not be combined with -w when starting console applications. Furthermore, the password should not be supplied when redirecting passwords when starting console applications. This switch should not be used with redirected passwords. -dn Do not switch to new desktop. If the new process is set to run on a desktop which differs from the current desktop, the default behavior is to switch to the new desktop, making the new desktop active and bringing it to the foreground. This option overrides the default and prevents switching to the new desktop. Note that SU does not return until the new process exits, unless the -w switch is specified. -e Disable environment preparation. The parent environment is inherited. This option prevents preparation of the user environment for the new process, instead causing the environment to be inherited from SU. -l Disable loading of the user Registry hive. .Default is used instead. This option prevents loading of the user Registry hive for the target user. If the hive happens to be loaded for the target user, the new process behaves the same way with HKEY_CURRENT_USER that it would if -l were not specified. If -l is specified without -e, a user default environment is created for the new process, as opposed to creating a user-specific environment for the new process. -v Display verbose output to STDOUT (standard output). This opti
Re: the "kill" command
You have a point. I cannot kill some windows in processes "directly" within the bash environment either. But this works EVERY time: cmd /c kill --force Try it, you'll like it. p.s. It'd be nice if it worked "as advertised" ;-) I ain't demand'n nothin! Whoever you are, and no matter where life finds you - your patch will be ready before mine! Brian Kelly "Tremaine Floyd" <[EMAIL PROTECTED]>@cygwin.com on 07/06/2003 08:00:21 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:the "kill" command I was wondering if there is a way to "kill" windows processes ? I use the "ps -W" cmd however I am not able to close windows based applications or windows expect the cygwin console itself. i have tried "kill -f" which actually brings back "bash: kill: f: invalid signal specification" & also tried "kill 9" but niether will shutdown a windows2000 application. Could I get a little with this please ? _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- 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/ "WellChoice, Inc." made the following annotations on 07/06/2003 08:26:08 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 "kill" command
I'll "try it again". In all fairness, I started using this method more than two years ago when kill - I would guess - really DID have a problem killing some windows processes. It may indeed be that it got fixed somewhere between now and then - or that I'm an idiot. Either way, if it now works - I'll smile. "Cygwin" - comes with a lifetime "money back guarantee" if not satisfied for any reason! ;-) Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 07/06/2003 08:37:15 PM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: the "kill" command On Sun, Jul 06, 2003 at 08:24:12PM -0400, [EMAIL PROTECTED] wrote: > >You have a point. I cannot kill some windows in processes "directly" within >the bash environment either. >But this works EVERY time: > > cmd /c kill --force > >Try it, you'll like it. Or, you could just do what I suggested, which is much easier than the above. >p.s. It'd be nice if it worked "as advertised" ;-) It works as advertised. You just have to meditate on the difference between a bash built-in and an actual program like /bin/kill.exe . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 07/06/2003 09:19:12 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Windows Security Hole??
I work in a large corporation with an obsessive security staff. Cygwin is now "accepted" (unofficially) through the "grease gun" method. In WWII one Nazi gunmaker was developing the world's first assault weapon. Hitler was informed of the effort - deemed it a waste of resources and ordered the project cancelled. A procurement general recognized the need for the weapon, and quietly "forgot" to cancel the program. A year or so later, the weapon was produced and distributed to German soldiers on the Eastern front. One day Hitler met briefly with some field commanders from the Eastern front and asked if they needed anything. "We need more of these new guns!" What new guns? Was Hitler's reply Defying Hitler was NOT a good career move for anyone! So what do you think happened to the general who "forgot" to cancel the weapon program? HE WAS COMMENDED!!! Oh but what a risk he took indeed. I took a similar risk where I work. Living by the philosophy that I can do anything until threatened with termination in a face to face meeting (Boiler plate threats in corporate mass e-mails are delete key fodder), I went ahead and used Cygwin and Perl to build an incredibly powerful automated deployment and automated encrypted B2B communications infrastructure. The alternative is expenditure in the hundreds of thousands of dollars for third party software, licenses, consultants etc, etc. By the time I was "outed", management was faced with a cruel dilemma - live by their own rules and spend money they never budgeted for projects they never fully grasped nor understood, or accept the "unacceptable" - production processes running on non-proprietary "open source" software. OH THE HORROR!!! The result - I WAS COMMENDED. The point is Windows ITSELF is a SECURITY HOLE. You'd hardly do worse running cygwin on it if you have any kind of security consciousness and use good practices and policies. Your problem is, you were probably caught "too early" before you could do something truly valuable and impressive with it that would be VERY expensive to replace. Everything in life is a cost-benefit analysis. Sell a benefit, or impose a cost, and you will succeed in your agenda more often than not. Unfortunately, the bigger the organization, the more SIGNIFCANT the cost or benefit has to be to succeed in successfully creating change. Running emacs is probably not "significant" enough - unfortunately. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Russo Sent: Wednesday, July 16, 2003 8:54 PM To: [EMAIL PROTECTED] Subject: Windows Security Hole?? Greetings all- I work for a corporation that is completly incased with windows. I currently have Win2K installed on my pc along with cygwin. My security dept became aware of this and now has asked me to remove cygwin because it represents a security breetch to the organization. Does running cygwin open any security 'holes' in a Win2K networked environment?? My thinking in this matter is that any information that I send while in cygwin would get 'encapsulated' and passed to Windows to determine what to do with it. Therefore, any security setting (GPOs, etc) are still enforced. I'm really only using it to run my perl scripts and have access to emacs. Any help or insight into this matter would be greatly appreciated... cheers, dr __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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: GPL alert ? http://thinstall.com/unix_tools/
Not only that, but this appears to go even further. By essentially "compiling" all these GNU utilities into one executable, there's a violation of the GPL to the extent that the code used to do that does not appear to be "Open Source". Double Whammy here. And by the way - I AM a lawyer. (Member of the Michigan Bar Association in Good Standing). Brian Kelly "Robert Collins" <[EMAIL PROTECTED]>@cygwin.com on 07/28/2003 07:26:26 AM Sent by:[EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:GPL alert ? http://thinstall.com/unix_tools/ http://thinstall.com/unix_tools/ seems to have cygwin binaries w/out source. Rob -- GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>. "WellChoice, Inc." made the following annotations on 07/28/2003 07:55:01 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement signature.asc 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: GPL alert ? http://thinstall.com/unix_tools/
OUTPUT FROM COMMAND: bash -v __ bash.exe: warning: could not find /tmp, please create! You are now running bash.exe from the Cygwin package This message is being presented by adding a virtual .bashrc file and having Thinstall automatically set the HOME directory before running this EXE. No changes have been made to bash or any other program in this package. Every program you execute from this command line will be loaded by Thinstall. To see which utilies have been packaged into one EXE execute the command : ls -las *.exe Each file listed will show the original uncompressed size All files will appear to be in the directory where you Originally ran this program from which was: /cygdrive/d/Documents and Settings/Administrator/Desktop If you have questions about what Thinstall can do for you contact Jonathan Clark at [EMAIL PROTECTED] bash-2.05b$ bash -v bash.exe: warning: could not find /tmp, please create! cd "$HOME"; echo "You are now running bash.exe from the Cygwin package" You are now running bash.exe from the Cygwin package echo "This message is being presented by adding a virtual .bashrc file" This message is being presented by adding a virtual .bashrc file echo "and having Thinstall automatically set the HOME directory" and having Thinstall automatically set the HOME directory echo "before running this EXE. No changes have been made to bash" before running this EXE. No changes have been made to bash echo "or any other program in this package." or any other program in this package. echo echo "Every program you execute from this command line will be" Every program you execute from this command line will be echo "loaded by Thinstall. To see which utilies have been packaged" loaded by Thinstall. To see which utilies have been packaged echo "into one EXE execute the command :" into one EXE execute the command : echo echo "ls -las *.exe" ls -las *.exe echo echo "Each file listed will show the original uncompressed size" Each file listed will show the original uncompressed size echo "All files will appear to be in the directory where you" All files will appear to be in the directory where you echo "Originally ran this program from which was:" Originally ran this program from which was: echo $HOME /cygdrive/d/Documents and Settings/Administrator/Desktop echo echo "If you have questions about what Thinstall can do for you" If you have questions about what Thinstall can do for you echo "contact Jonathan Clark at [EMAIL PROTECTED]" contact Jonathan Clark at [EMAIL PROTECTED] echo bash-2.05b$ _ AND NOW OUTPUT FROMbash --version _ bash-2.05b$ bash --version bash --version bash.exe: warning: could not find /tmp, please create! GNU bash, version 2.05b.0(2)-release (i686-pc-cygwin) Copyright (C) 2002 Free Software Foundation, Inc. bash-2.05b$ _ SEEMS LIKE AN OPEN AND SHUT CASE TO ME! Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 07/28/2003 09:19:44 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: GPL alert ? http://thinstall.com/unix_tools/ On Mon, Jul 28, 2003 at 07:52:36AM -0400, [EMAIL PROTECTED] wrote: >Not only that, but this appears to go even further. By essentially >"compiling" all these GNU utilities into one executable, there's a >violation of the GPL to the extent that the code used to do that does >not appear to be "Open Source". Double Whammy here. > >And by the way - I AM a lawyer. (Member of the Michigan Bar >Association in Good Standing). I noticed that but i was wondering if these were actually cygwin tools. Has anyone verified that? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 07/28/2003 09:43:52 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that
RE: Source code for binaries offered at http://thinstall.com/ ?
Mr. Clark, I almost never put on my attorney's cap anymore, but I am ethically bound to offer one piece of advice when I see that it is truly called for. Please, seek out and consult with an experienced software and intellectual property rights attorney at your earliest possible opportunity. You've got a very nifty little utility, but then again, so did Napster. I am not a software law specialist, nor have I specialized in intellectual property when I did formally pratice, but I know enough to see that there are lot of legal issues you have not investigated in depth - and I STRONGLY advise that you do so with the assistance of an experienced counselor. Brian Kelly, J.D. "Jonathan Clark" <[EMAIL PROTECTED]>@cygwin.com on 07/28/2003 07:01:18 PM Sent by:[EMAIL PROTECTED] To:"Max Bowsher" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: Source code for binaries offered at http://thinstall.com/ ? Hello Max, This is a good point. I have the source downloaded and in backups somewhere around here - so it can be located if needed. While I'm in the process of putting together a new archive that contains more GPL disclaimers (and more utilities), I wish to be in compliance by offering a CDROM for those that desire it. Best Regards, Jonathan Clark President / Jitit 155 Jackson St. #408 San Francisco, CA 94111 1-415-274-2558 -Original Message- From: Max Bowsher [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 2:40 PM To: Jonathan Clark; [EMAIL PROTECTED] Subject: Re: Source code for binaries offered at http://thinstall.com/ ? Jonathan Clark wrote: > Hi Christopher, > > I see, I thought this condition was to eliminate the need to mirror the > source > if you are simply redistributing binaries that already have source mirrors. > > If it meets your approval for satisfying the GPL, I will add the following > information: > > "Some programs inside of this archive use unmodified binaries from the > Cygwin project which is released under the GPL license. Source code for > these programs can be downloaded from: > http://sources.redhat.com/cygwin/download.html > > Additionally, source code for these programs is available on CDROM for the > cost of postage. For more information on how to obtain the CDROM, email > [EMAIL PROTECTED]" > > As soon as I get a request for CDROM, I will package it up and post on the > web site as well - but so far people have been content to download it from > cygwin website. If you don't package up the specific source *now* how will you know and obtain the source when you do receive a request? There is no guarantee that the exact version you are distributing will still be on the Cygwin mirrors. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 07/28/2003 08:03:22 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Source code for binaries offered at http://thinstall.com/ ?
My concern is that issues surrounding Mr. Clark's use of cygwin goes well beyond just supplying source on his website. It appears that the raison d'etre for his software is to simplfy software distribution, and "can up" processes and process combinations for very tailored purposes - a worthwhile endeavor. However, looking at it from a different angle, what he's actually done is create a kind of super compiler that "links" executables together as if they were methods that one would find in the cygwin1.dll. In fact, neither he nor anyone else can run bash without the cygwin1.dll. By "slurping" up the cygwin1.dll into a proprietary binary structure and combining it not only with the proprietary environment that enables it's operation, but potentially with other standalone binary utilities that may run the gamut from open source, to shareware to extremely proprietary - i.e - one license per machine for sequential, not simultaneous processing only - how does that differ conceptually from a compiler linking a proprietary method with a cygwin method found in the cygwin1.dll into a stand-alone executable??? Such a use - if one hopes to distribute such a binary for a fee - requires a contractual agreement with Red Hat, along with payment of a rather NOT insignificant (if I may say so myself) licensing fee. This utility looks like a great way to "trojan horse" licensed software into a binary structure that would mask it's very existence. A pirate's dream come true perhaps - at least when used and examined by unsophisticated users - which make up the vast majority. This is why I urged Mr. Clark to consult an experienced attorney. He needs to inform his user base that licensing restrictions apply to everything bundled with his utility - and even if the final executable is not sold for a fee, but distributed in such a way that the stand-alone executable may change hands many times, it may even be necessary that the source for any and all GPL'd software be included IN the executable itself in such a way that it can be exported to a text file with a command line switch. Certainly including the source on a distribution cd and the website goes a long way towards satisfying this requirement. However, one way such a binary would be useful would be in a process "chain" - where the bundle actually is used to support a distributed operation B2B, over the internet, etc. In such a chain the final package would arrive after traveling through many "highways". Traversing such journeys with "source in tow" may not always be practical. Furthermore, new and uneducated recipient's of such an executable NEED to know about it's contents, the licensing restrictions of those contents, and prohibitions of duplicating the bundled executable without satisfying ALL licensing restrictions of ALL its contents - INCLUDING the distribution of source for any and all bundled GPL software. Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 07/28/2003 11:19:04 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Source code for binaries offered at http://thinstall.com/ ? On Mon, Jul 28, 2003 at 10:12:07PM -0400, Jon A. Lambert wrote: >From: "Carlo Florendo" <[EMAIL PROTECTED]> >> From: "Jonathan Clark" <[EMAIL PROTECTED]> >> Subject: RE: Source code for binaries offered at http://thinstall.com/ ? >> >> > Hello Max, >> > >> > This is a good point. I have the source downloaded and in backups somewhere >> > around here - so it can be located if needed. While I'm in the process of >> > putting together a new archive that contains more GPL disclaimers (and more >> > utilities), I wish to be in compliance by offering a CDROM for those that >> > desire it. >> > >> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites >> > >GPL > 3. You may copy and distribute the Program (or a work based on it, >under Section 2) in object code or executable form under the terms of >Sections 1 and 2 above provided that you also do one of the following: >... >b) Accompany it with a written offer, valid for at least three ^ This would require sending a written offer to every person who purchases your software. "Written" is not email. It's an actual letter. I'll say it again: We have consulted with experts. The FSF FAQ entry is really correct here. If you are offering binaries on a web site, you need to offer sources on the web site, too. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentati
RE: Source code for binaries offered at http://thinstall.com/unix_tools ?
As long as the *complete* binary contents can be extracted then I would essentially agree that Thininstall is fundamentally no different than an ordinary zip archive. No one has implied to my knowledge - especially me - that you were *actually* "selling" unix_tools - but that there certainly would be issues if one ever contemplated selling a binary of any kind that contained GPL'd software - even if the GPL'd software was used only to install a separate package and did not constitute the functionality actually being "sold". And while being able to put unix_tools on a floppy is a cool thing, from a legal standpoint, anyone who permanently passes that floppy or makes a copy for others to use is in fact "distributing" GPL'd software and must also have the exact source *readily* available - i.e., on the floppy or archived within the Thininstall created binary (or "archive" if one so pleases) itself. Of course anyone who creates their own floppy for their own use is exempted. Brian Kelly "Jonathan Clark" <[EMAIL PROTECTED]>@cygwin.com on 07/29/2003 12:47:59 PM Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: Source code for binaries offered at http: //thinstall.com/unix_tools ? I will write up some documentation soon about the GPL issue, but a quick clarification: 1. Some emails have mentioned unix_tools as being commercial and that I have customers who "purchased" it. unix_tools is free (as in beer), always has been, always will be - it is something I made to be a handy tool and to show off the power of Thinstall and make freely available at no charge. I've found a lot of people find it is a handy utility to have on hand, especially since it is runnable from a floppy. I realize the fact that unix_tools is free does not change any GPL issues, but just wanted to point this out. 2. Thinstall does not modify the binary structure (i.e. bytes) of files it "links" together other than to provide compression. In this manner it's no different from zip or tar. All files can be copied from the compressed file system to hard drive with their exact original contents. This is easily demonstrated by running the bash example and typing the command "cp -R * /cygdrive/c". The term "link" is used in documentation to illustrate the point that the files may be used without extracting to disk - however in fact, there is no link between any files except that they are all located in the same archive. "compile", "link", etc are used as marketing terms to illustrate this is new technology - not a self-extracting ZIP where files must first be copied outside the archive - but Thinstall in no way resembles a compiler or linker at the implementation level. The Thinstall OS is able to run EXEs and load DLLs both inside and outside of the archive. Simply running an GPLed EXE located on in a compressed filesystem can not invoke GPL on the loading OS or most operating systems would fall under this umbrella. Likewise, having an OS located in the same archive as GPL software would not somehow require it to be GPLed or we could open source Windows tomorrow because I do this all the time with VMWare. :) Thinstall works with all EXEs, DLLs, and files, and has no direct tie or dependency on any GPL software or components. More user-info related to this discussion: http://thinstall.com/help/index.html?virtualoperatingsystem.htm (The OS) http://thinstall.com/help/createprocessshellexecuteo.htm (Loading external EXEs) http://thinstall.com/help/index.html?externaldllloading.htm (Loading external DLLs) Best Regards, Jonathan Clark -Original Message- From: Williams, Gerald S (Jerry) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 4:58 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Source code for binaries offered at http://thinstall.com/ ? Brian Kelly wrote: > Please, seek out and consult with an experienced software and > intellectual property rights attorney at your earliest possible > opportunity. You've got a very nifty little utility, but then > again, so did Napster. [ ... ] > I know enough to see that there are lot of legal issues you > have not investigated in depth - and I STRONGLY advise that you > do so with the assistance of an experienced counselor. Jonathan, I don't want to tie up our mailing lists with this, and I'm sure the GPL licensing lists address it better, but please listen to him if you haven't already done so. Your online help indicates that Thinstall *links* target libraries, executables, and such. That certainly sounds like it would trigger the GPL (i.e., everything else you link into that executable would have to fall within the GPL guidelines). Personally, I'd get something in writing from the FSF or RMS or some
xinetd cannot find the SYSTEM account on 2000
After spending about four hours trying to get xinetd going (specifically telnet), I've run out of ideas. Currently I can run telnet flawlessly with inetd using a domain account. I'm not entirely sure what account inetd is using to run because I used the --install-as-service option which worked flawlessly. The passwd entry was created with mkpasswd -d -u userid and again - works flawlessly for inetd. When I run xinetd as /usr/sbin/xinetd -d, it tells me it cannot locate the SYSTEM account. It also complains that it cannot locate any LOCAL account that I specify. However, it will give me a login prompt if I specify the domain ID that I am currently logged into the system with - in the /etc/xinetd.d/telnet configuration file. However it won't authenticate the very same ID when I attempt to connect to the localhost via telnet. Tells me the password is invalid. Kill xinetd, and start inetd again, and telnet again works flawlessly. Anybody got a clue what I'm missing here? Brian Kelly "WellChoice, Inc." made the following annotations on 08/01/2003 08:12:43 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Has ANYONE got telnet via xinetd working on 2000 *SERVER*??( or 2003)
WOW! Thanks dude! You're my hero! YES - I would *GREATLY* appreciate: "edit to make appropriate to xinetd (available on request)" So I am hereby *requesting* it :-) It still *seems* like I did everything here (and more than once I might add) - and that I *should* have got it working. Of course I will start fresh and follow your instructions *to the letter* and then backstep to see why I wasn't able to get it working on my own. The one thing of course that I would never have thought to do would be to copy and modify sshd to xinetd. Not exactly *intuitive*! I'll be anxious to see if this was indeed the one indispensible thing I needed to do. Again - appreciate all the assistance. I need xinetd to maximize security until we can get secure shell working from the mainframe (don't hold your breath!). Ah well, some folks just like liv'in in the past! Brian Kelly "Vince Hoffman" <[EMAIL PROTECTED]> on 08/06/2003 08:41:38 AM To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] cc: Subject:RE: Has ANYONE got telnet via xinetd working on 2000 *SERVER*?? ( or 2003) had time to try this today, works fine. steps were, 1) clean install included inetutils, xinetd, sysvinit ,chkconfig and initscripts (and vim but whatever editor you like ;) 2) run /usr/bin/init-config, NOT overwriting any config files, just to install init as a service. 3) copy /etc/rc.d/init.d/sshd to /etc/rc.d/init.d/xinetd and edit to make appropriate to xinetd (available on request) 4) cd /etc/rc.d/init.d then /usr/sbin/chkconfig --add xinetd 5) net stop init net then net start init 6) $ telnet localhost Trying 127.0.0.1... Connected to GENBRIDEVINT1.uk.circle.com. Escape character is '^]'. CYGWIN_NT-5.0 1.3.22(0.78/3/2) (GENBRIDEVINT1) (tty0) login: administrator Password: Fanfare!!! You are successfully logged in to this server!!! [EMAIL PROTECTED] ~ $ ps -e PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1684 11684 1684 con 500 13:25:25 /usr/bin/bash 2076 12076 2076? 18 13:33:22 /usr/bin/cygrunsrv 199220761992 2016? 18 13:33:22 /sbin/init 1756 11756 1756? 18 13:33:23 /usr/sbin/xinetd 195216841952508 con 500 13:39:57 /usr/bin/telnet 182417561824 1016? 18 13:39:58 /usr/sbin/in.telnetd 180418241804 15600 500 13:40:11 /usr/bin/bash 227618042276 22880 500 13:40:49 /usr/bin/ps [EMAIL PROTECTED] ~ $ Hope this helps. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 06 August 2003 01:28 > To: [EMAIL PROTECTED] > Subject: Has ANYONE got telnet via xinetd working on 2000 > *SERVER*?? (or > 2003) > > > I've got invested about seven to eight total hours trying to get it > working, plowing past > one issue after another. I finally get a login prompt, but I can't > authenticate with ANY ID, > local or domain. Inetd on the other hand, works perfectly. I > read folks had > trouble getting > similiar stuff working on 2003 Server. Could it be that 2000 > server and > 2003 server really > aren't all that different?? > > Anyway, before I saddle you guys with "stuff", I thought I'd > first ask if > *anyone* is using > it successfully on 2000 *Server*. > > Brian Kelly > > > > > "WellChoice, Inc." made the following > annotations on 08/05/2003 08:29:55 PM > -- > > Attention! This electronic message contains information that > may be legally > confidential and/or privileged. The information is intended > solely for the > individual or entity named above and access by anyone else is > unauthorized. > If you are not the intended recipient, any disclosure, > copying, distribution, > or use of the contents of this information is prohibited and > may be unlawful. > If you have received this electronic transmission in error, > please reply > immediately to the sender that you have received the message > in error, and > delete it. Release/Disclosure Statement > > > -- > 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/ > "WellChoice, Inc." made the following annotations on 08/06/2003 10:52:38 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The informati
Re: Win2k and cygwin memory leak
> What a clueless comment. H - I'll go with that!! (if it makes you feel better - or even if it doesn't) > It is not "denial" to assert that an OS which allocates memory and doesn't > free it is broken. If cygwin triggers a windows problem that does not mean > that it is a cygwin problem no matter how hard that is for you to understand. Gosh, isn't there a *win* in *cygwin*?? Not that I'm "demanding" anything or goodness knows, making suggestions about how you 'Oh Great One' should allocate your resources - goodness *no*! But this notion that a WinDoze problem is not *also* a cyg*win* problem - is quite a *CURIOUS* one to this *clueless* simpleton - INDEED!! Seems in a way that you're saying "I don't care if what I built doesn't work for this or that because it's Microsoft's problem". I really don't think you as one who is quick to let Microsoft define what he can and can't do - as you yourself have said "I fix all sorts of problems in cygwin which are really windows problems" So indeed you pick and choose which *Microsoft* problems to fix that keep cyg*win* from working - all along *denying* it's a cyg*win* problem . Interesting how a 'Great' mind works ;-) . Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 01:56:16 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Thu, Aug 07, 2003 at 12:52:53PM -0400, [EMAIL PROTECTED] wrote: >Ah well, someday the denial will end, or the problem will get fixed >unintentionally when some other change is made and the "cygworld will >go on". What a clueless comment. It is not "denial" to assert that an OS which allocates memory and doesn't free it is broken. If cygwin triggers a windows problem that does not mean that it is a cygwin problem no matter how hard that is for you to understand. I fix all sorts of problems in cygwin which are really windows problems but, golly gee, if I can't duplicate them, I can't fix them. And, my willingness to debug some things is limited. If it takes running a perl script every five minutes for a day to duplicate the problem, then that is not something that I'm going to do anytime soon. This is not denial. This is a refusal to take a large amount of my time to find a workaround to a windows problem. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/07/2003 02:35:24 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
May I call you "Jim"? I may be clueless, but I'm not stupid. I would never question King Faylor's ability to find and fix, or work around a memory leak (and I even respect his decision not to) but I would certainly question yours As for the venom being spewed on this thread, all I want to say is that I spent hundreds of hours cobbling together work-arounds so I could get an open source automated infrastructure working in a large organization. Cygwin is just one piece of the puzzle - but it is a critical indispensible piece. I consider my time just as ( if not more ) valuable than anyone else's participating here. These "disputed" memory leaks were for me the biggest obsticle preventing me from achieving my ultimate objective - which saved my company hundreds of thousands of dollars they otherwise would have had to spend to acquire the solution from third party vendors. It would have been "nice" if there was an acknowledgement of this problem (cygwin's or not) rather than attempted character assassinations. But the value that Cygwin delivers for me and my organization is so valuable and irreplacible that *putting up* with the *meanness* here is small price to pay to get the answers I frequently need. "Jim Drash" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 04:18:16 PM Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak I will be happy to find and fix your specific memory leak. My going rate is $200/hour. If that is satisfactory with you we can talk. If not, you have the source, the compiler, the debugger, find it yourself or find someone who will at a lower rate than mine. Otherwise, "bugger off!" -- 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/ "WellChoice, Inc." made the following annotations on 08/07/2003 05:00:58 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Has ANYONE got telnet via xinetd working on 2000 *SERVER*??( or 2003)
BOY - WAS THAT PAINFUL. I did *finally* get it all working - but it sure seems like there's got to be an easier way. Some lessons learned: 1.If you were set up for inetd *before* you attempt to use xinetd, be sure to set the CYGWIN environment variable. CYGWIN='binmode tty ntsec' I had the registry modified instead for inetd and it didn't occur to me till after about 12 hours of trying everything else that this could be the culprit. 2.I found that copying the sshd to xinetd was not necessary. The default one that is put down with the xinetd install seems to work just fine. 3.Be sure to run iu-config in addition to everything else to set up the /etc environment if cygwin is truly a fresh install. 4.Make sure that /var/log is universally writable. If the xinetd service doesn't start when doing net start init then stop init service, remove /var/log/servicelog and make sure /var/log directory is writeable for all. Start init service. (Thanks to Sergey Okhapkin). Telnet/Ftp via Xinetd INSTALL - SETUP Instructions ### 1.Do a clean install (or REINSTALL) of inetutils, xinetd, sysvinit, chkconfig, and initscripts Note: inetd will NOT be running as a service, but the xinetd does need inetutils installed. Beyond simply putting the pieces on your harddisk via setup.exe, DO NOT follow any of the instructions regarding *inetd*. 2.Make sure your CYGWIN enviroment variable is set: CYGWIN='binmode tty ntsec' 3.run /bin/iu-configto set up the /etc folder. 4.run /usr/bin/init-config, NOT overwriting any config files, just install init as a service 5.cd /etc/rc.d/init.d then /usr/sbin/chkconfig --add xinetd 6.net stop init then net start init 7.telnet localhost THANKS VINCE!! # > had time to try this today, works fine. > steps were, > 1) clean install included inetutils, xinetd, sysvinit ,chkconfig and > initscripts (and vim but whatever editor you like ;) > 2) run /usr/bin/init-config, NOT overwriting any config files, just to > install init as a service. > 3) copy /etc/rc.d/init.d/sshd to /etc/rc.d/init.d/xinetd and > edit to make > appropriate to xinetd (available on request) > > 4) cd /etc/rc.d/init.d then /usr/sbin/chkconfig --add xinetd > > 5) net stop init net then net start init > > 6) > $ telnet localhost > Trying 127.0.0.1... > Connected to GENBRIDEVINT1.uk.circle.com. > Escape character is '^]'. > > CYGWIN_NT-5.0 1.3.22(0.78/3/2) (GENBRIDEVINT1) (tty0) > > login: administrator > Password: > Fanfare!!! > You are successfully logged in to this server!!! > "Vince Hoffman" <[EMAIL PROTECTED]>@cygwin.com on 08/06/2003 11:32:29 AM Sent by:[EMAIL PROTECTED] To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, "Vince Hoffman" <[EMAIL PROTECTED]> cc:[EMAIL PROTECTED] Subject:RE: Has ANYONE got telnet via xinetd working on 2000 *SERVER*?? ( or 2003) > > > WOW! Thanks dude! You're my hero! YES - I would *GREATLY* appreciate: > > "edit to make appropriate to xinetd (available on request)" > > So I am hereby *requesting* it :-) > as requested (find attached) its probably not a tidy as could be as i just ripped out the ssh specific bits, did %s/sshd/xinetd/g %s/SSHD/XINETD/g so remembering i did actualy have access to a redhat box using linux box using xinetd, find attached also, xinet.rh which is the redhat one with linux specific stuff cut out (checking for root user etc.) havent tested that one but it should work. hope this is enough to get yours working. On a side note, i originaly tried to use just xinetd as a service but realised there is no option to stop it forking to background so while it worked, you couldnt stop it without killing it from a command line/task manager :(. > It still *seems* like I did everything here (and more than > once I might > add) - and that > I *should* have got it working. Of course I will start fresh > and follow > your instructions > *to the letter* and then backstep to see why I wasn't able to get it > working on my own. > > The one thing of course that I would never have thought to do > would be to > copy > and modify sshd to xinetd. Not exactly *intuitive*! I'll be > anxious to see > if this was > indeed the one indispensible thing I needed to do. > > Again - appreciate all the assistance. I need xinetd to > maximize security > until we can > get secure shell working from the mainframe (don't hold your breath!
proftpd issues
Since having gotten xinetd working, I've shifted my effortst to the new proftpd. After another couple of hours of *pain* - I finally got it going in a limited fashion. First of all, I couldn't get it to start with the SYSTEM id as indicated in the proftpd.conf file. I had to use a custom ID added to the Administrators group and having the following User Rights assigned: "Act as part of the operating system" "Replace process level token" "Increase quotas" Question: Do these rights *have* to granted to the SYSTEM id for proftpd to work? Next - I could log on with local id's - but not with Domain id's. Is proftpd set up to do domain authentication via ntsec?? If not, is there an ETA? Brian Kelly "WellChoice, Inc." made the following annotations on 08/08/2003 05:35:21 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
;-) bk "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/08/2003 11:13:02 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Fri, Aug 08, 2003 at 09:01:14AM -0400, [EMAIL PROTECTED] wrote: >Seems to little ole *clueless* me, such such issues could be addressed >in that project. Seems like it'd be a heck of lot more congenial and >productive to engage in creative "what if" scenario's about future >developmemt possibilities than knee jerk character attacks. (Of course >I realize that's more of a cygwin-app discussion - but it would >certainly work well to placate us clueless types in the meantime.) This is by no means a cygwin-app discussion. Read http://cygwin.com/lists.html . >I've made no demands, asked for no status, and set no deadlines. Just still >*dumbfounded* at the "go tell it on the Microsoft" posturing. Hopefully you are not referring to me. I suggested that interested parties could do a Knowledge Base or google search. I guess you don't qualify. For the record, I called a comment of yours clueless. I did not label you personally. You seem to be having fun doing that to yourself, though, so I'm glad I offered you some enjoyment. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/08/2003 12:44:21 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Has ANYONE got telnet via xinetd working on 2000 *SERVER*?? (or2003)
I've got invested about seven to eight total hours trying to get it working, plowing past one issue after another. I finally get a login prompt, but I can't authenticate with ANY ID, local or domain. Inetd on the other hand, works perfectly. I read folks had trouble getting similiar stuff working on 2003 Server. Could it be that 2000 server and 2003 server really aren't all that different?? Anyway, before I saddle you guys with "stuff", I thought I'd first ask if *anyone* is using it successfully on 2000 *Server*. Brian Kelly "WellChoice, Inc." made the following annotations on 08/05/2003 08:29:55 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
> Seems like your saying that (using a car analogy) he should replace the > carberator when the real problem is a leak in the fuel line. (IOW > you're attacking the wrong area - your problem lies elsewhere). Nope - gotta lower your expectations. I use to work in shop when I was in high school. Bascially I'd snip the line at the leak, get a piece of rubber hose and a couple of hose clamps. Back on the road in five minutes!! - Oh but that's not SAFE ( you may counter ) ( to which I would say ) - neither are crashing servers ... Assuming of course we stick to your analogy and assume that I can't 'replace' the fuel line because - well - it's "Ford's" problem . You see, basic people (clueless) are very practical. Why put in a new engine when a piece of duct tape will do??? "Andrew DeFaria" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 02:58:10 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak [EMAIL PROTECTED] wrote: > Gosh, isn't there a *win* in *cygwin*?? Not that I'm "demanding" > anything or goodness knows, making suggestions about how you 'Oh Great > One' should allocate your resources - goodness *no*! But this notion > that a WinDoze problem is not *also* a cyg*win* problem - is quite a > *CURIOUS* one to this *clueless* simpleton - INDEED!! Sticking three letters in a name does not make Cygwin == Windows. It is the job of the OS to manage memory not the job of the program. When a process ends the OS is responsible for cleaning up any of the resources that the process aquired. If the OS fails to do this then it's the OS that needs to be fixed, not the process. > Seems in a way that you're saying "I don't care if what I built > doesn't work for this or that because it's Microsoft's problem". Seems like your saying that (using a car analogy) he should replace the carberator when the real problem is a leak in the fuel line. (IOW you're attacking the wrong area - your problem lies elsewhere). > I really don't think you as one who is quick to let Microsoft define > what he can and can't do - as you yourself have said Are you asking Cygwin to re-write and take control of management of memory from the OS?!? That's like asking the carberator mechanic to build his own fuel line running outside the body of the car! > So indeed you pick and choose which *Microsoft* problems to fix that > keep cyg*win* from working - all along *denying* it's a cyg*win* > problem . Yes because some problems are fixable or are within the domain of where Cygwin has proper control. You can fix a carberator to get extra house power but if the main engine only has 2 cyclinders don't ask the carberator mechanic to get 8 cyclinder performance - talk to the maker of the engine itself! > Interesting how a 'Great' mind works ;-) . Interesting how a clueless mind wanders off... -- 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/ "WellChoice, Inc." made the following annotations on 08/07/2003 03:45:09 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
Now seems to be a good time for me to jump in. I can DEFINITIVELY say that *something* within cygwin - or perl (using Cygwin's perl) - causes a very real and very measurable memory leak. I run a 24-7 automated FTP encryption architechture using cygwin cron which launches a perl script that automates telnet and ftp from the inetutils package. After each invocation, memory is lost. The only thing that keeps the box from dying completely is that in the very same crontab I call - four times a day - a memory manager called *RAMpage* which is also open source and can be invoked from the command line. This program frees up the lost memory allowing me to essentially run the server indefinitely. I would of course rather not have to use RAMpage at all - but since there's ongoing denial about the existence of "memory leaks" *somewhere* in the vastness of cygwin - I have no choice but to resort to that which *works*. Ah well, someday the denial will end, or the problem will get fixed unintentionally when some other change is made and the "cygworld will go on". In the meantime, I have a solution - kludgy you can be sure - but it works and has been doing so for nearly nine months. RAMpage => http://www.jfitz.com/software/RAMpage/ Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 11:40:57 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Thu, Aug 07, 2003 at 11:32:42AM -0400, Rolf Campbell wrote: >This may be a Win2000 problem, not a cygwin problem...What service pack >are you running? "May be"? You run a bunch of programs, exit them, and Windows slowly loses memory after each exit? Hard to see how that's a cygwin problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/07/2003 12:55:14 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
Assuming you're right - and I have no reason to think otherwise, using cygwin in a memory intensive fashion does indeed fragment the memory. *cygwin's problem?* OK - I'm being persuaded it isn't - as such. After playing with it some over the last few hours, I found that the problem is MUCH worse on NT4 than W2K. (NT4 was my only platform 11 months ago when the problem was first discoverd.) Basically NT4 degrades very quickly and I have yet to see it recover without RAMpage. W2K degrades also, but if left alone long enough, appears to recover on its own "eventually". The *eventually* is the key thing since if the memory fragments "fast enough" - I can cripple the box before the OS recovers on its own. This is where RAMpage is useful on W2K. Perhaps there is a registry or ini setting that one could tweak to force OS defragmenting earlier. It's all pretty new to me. The question is, is this fragmenting and defragging an unavoidable and inevitable side effect, or can it be managed from within an application? Can some of this be controlled with the cygwin daemon of the future? Anyhow, I too am weary of this thread and since I'm not a c/c++ programmer, I've exhausted most of the resources I can use on this question. Nevertheless, if others find RAMpage helps them to use cygwin more robustly than without, especially on older OS's like NT4 and win98, then a mention in the FAQ I think would be quite helpful. But I would think more feedback and experience from a wider cross section of folks would be needed first. Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/08/2003 11:15:36 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Fri, Aug 08, 2003 at 09:32:16AM -0400, [EMAIL PROTECTED] wrote: >>Looking at RAMpage's code and reading the description, I see nothing >>that indicates it would solve this supposed "memory leak" problem. All >>that it does is allocate a huge chunk of memory and free it, forcing >>any fragmented memory out onto disk. I really don't see how that would >>cause any improvement in anything related to a memory leak. > >I do not know much, but I do know this. With RAMpage running 4 times a >day, my server stays up. Without it, it crashes. The only thing >running on the box other than the naked OS and backup software and >Anti-virus, is cygwin and cygwin installed apps. I agree with you to >the extent that it certainly doesn't *solve* the *supposed* memory leak >problem. But it keeps my server up and I'm sure it will help others >too. If RAMpage is truly solving your problem then you should stop referring to the problem as a memory leak. AFAICT, although the web site is very misleading, RAMpage does not do anything to fix "memory leaks". It just defragments memory. It even says that it is not likely to fix problems on newer OSes like Win2K. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/08/2003 01:28:21 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: proftpd issues - Got it WORKING
Hi Jason, thanks for the response. OK - here's the scoop. *** I GOT IT WORKING with domain authentication *** After doing an strace, I found that proftpd could not validate a home directory via UNC conventions. In the domain enviroment I'm working on, the domain account I'm using for testing has it's *home* directory on a network shared resource - andmkpasswd -d -u loginname created an entry with the home directory set to//servername/users/loginname. proftpd could *not* validate this and therefore exited without attempting any further authentication. Once I changed the home directory setting in passwd to/home/loginnamethe domain login succeeded. On a further note, I was able to get the SYSTEM id working for proftpd. Turns out proftpd is HYPER sensitve to the permissions-owner-group settings for the /var directory tree. I resolved this by doing chown -R SYSTEM:Administrators /var That essentially fixed it. Futhermore, it was *not* necessary to have to provide any further user rights to the SYSTEM id. It is working in "inetd" mode. Brian Kelly "Jason Tishler" <[EMAIL PROTECTED]>@cygwin.com on 08/11/2003 07:10:45 AM Sent by:[EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: proftpd issues Brian, On Sat, Aug 09, 2003 at 09:12:57AM -0400, Brian Kelly wrote: > I'm sorry Igor, I'm not giving you enough info. proftpd is being > called from xinetd which itself is being launched via init. *telnet* > works fine and authenticates BOTH local and domain ID's. So that > *should* - correct me if I'm wrong - eliminate the passwd and group > file entries as culprits. Especially since I'm using the very same > domain ID for my testing. Does /var/log/ProFTPD.log indicated anything interesting when authentication fails. Can you strace the problem? What happens when you run proftpd in stand-alone mode -- not under xinetd? > Furthermore, if I change the ftp daemon to the one supplied with > inetutils, Domain authentication works again. FWIW, the authentication code in proftpd was copied from inetutils's ftpd. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/11/2003 09:45:14 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: proftpd issues
Thanks for the response Igor. I'm working on W2K *Server* SP3. Maybe the Servers are more stict with the User Rights?? Domain authentication works fine for telnet, and inetutils ftpd - but *not* for proftpd. Any ideas? I think there's a test version of proftpd sitting out on the mirrors - perhaps it has fixes for this? Brian Kelly "Igor Pechtchanski" <[EMAIL PROTECTED]> on 08/08/2003 06:50:16 PM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: proftpd issues On Fri, 8 Aug 2003 [EMAIL PROTECTED] wrote: > Since having gotten xinetd working, I've shifted my effortst to the new > proftpd. > > After another couple of hours of *pain* - I finally got it going in a > limited fashion. > > First of all, I couldn't get it to start with the SYSTEM id as indicated in > the proftpd.conf file. > > I had to use a custom ID added to the Administrators group and having the > following User Rights assigned: > > "Act as part of the operating system" > "Replace process level token" > "Increase quotas" > > Question: Do these rights *have* to granted to the SYSTEM id for proftpd to > work? Yes. Since you've as much as quoted from the ntsec userguide section, I'm not going to bother citing a reference. The above rights are needed to switch user contexts. SYSTEM has it by default on most NT-based versions of Windows (but may not on some more recent ones, notably 2003 server). > Next - I could log on with local id's - but not with Domain id's. Is proftpd > set up to do domain authentication via ntsec?? > If not, is there an ETA? > > Brian Kelly Cygwin (ntsec) is already set up for domain authentication. However, to be able to authenticate a domain user, that domain user has to be in /etc/passwd (and his groups should most likely be in /etc/group). Make sure your /etc/passwd includes the users you're trying to authenticate. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton "WellChoice, Inc." made the following annotations on 08/08/2003 08:09:21 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: proftpd issues
> Fixes for what? If proftpd needs to switch user contexts (using Cygwin > system calls), the account it runs under needs to have those rights. > Period. I'm sorry Igor, I'm not giving you enough info. proftpd is being called from xinetd which itself is being launched via init. *telnet* works fine and authenticates BOTH local and domain ID's. So that *should* - correct me if I'm wrong - eliminate the passwd and group file entries as culprits. Especially since I'm using the very same domain ID for my testing. [EMAIL PROTECTED] ~ - telnet 1**.24.2**.81 Trying 1**.24.2**.81... Connected to 1**.24.2**.81. Escape character is '^]'. CYGWIN_NT-5.0 1.3.22(0.78/3/2) (stp*ftp2) (tty0) login: bmk1n0 Password: Fanfare!!! You are successfully logged in to this server!!! [EMAIL PROTECTED] ~ - exit logout Connection closed by foreign host. [EMAIL PROTECTED] ~ - ftp 172.24.200.81 Connected to 1**.24.2**.81. 220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [stpn*ftp2. .com] Name (1**.24.2**.81:bmk1n0): bmk1n0 331 Password required for bmk1n0. Password: 530 Login incorrect. ftp: Login failed. 421 Service not available, remote server has closed connection ftp> bye ### NOW LOCAL ID - SAME AS PROFTPD IS SET TO # [EMAIL PROTECTED] ~ - ftp 1**.24.2**.81 Connected to 1**.24.2**.81. 220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [stp*ftp2. .com] Name (1**.24.2**.81:bmk1n0): root 331 Password required for root. Password: 230 User root logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> %% Furthermore, if I change the ftp daemon to the one supplied with inetutils, Domain authentication works again. The *root* ID was created as new local ID on the ftp2 box. I have explicitly assigned the rights: "Act as part of the operating system" "Replace process level token" "Increase quotas" It is a member of the administrator's group. As you can see, the server runs with this ID, and authenticates this ID, but not Domain ID's. Also, it simply will *not* run with the SYSTEM ID, although telnetd *is* running with it. Thanks Brian Kelly "Igor Pechtchanski" <[EMAIL PROTECTED]> on 08/08/2003 08:57:53 PM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: proftpd issues Fixes for what? If proftpd needs to switch user contexts (using Cygwin system calls), the account it runs under needs to have those rights. Period. If the SYSTEM account doesn't have those rights on your machine, it's nothing that proftpd can fix. You'll just need to either create an account with those rights, or add them to an existing account. As for domain authentication, are the entries for the domain users you're trying to authenticate present in your /etc/passwd file? Are their corresponding groups in /etc/group? Just to eliminate that possibility, could you please run "mkpasswd -d yourdomain >> /etc/passwd" and "mkgroup -d yourdomain >> /etc/group" before trying again? You may want to save backup copies of /etc/passwd and /etc/group first. Igor On Fri, 8 Aug 2003 [EMAIL PROTECTED] wrote: > Thanks for the response Igor. I'm working on W2K *Server* SP3. Maybe the > Servers are more stict with the User Rights?? Domain authentication > works fine for telnet, and inetutils ftpd - but *not* for proftpd. Any > ideas? I think there's a test version of proftpd sitting out on the > mirrors - perhaps it has fixes for this? > > Brian Kelly > > > "Igor Pechtchanski" <[EMAIL PROTECTED]> on 08/08/2003 06:50:16 PM > > Please respond to [EMAIL PROTECTED] > > To:[EMAIL PROTECTED] > cc:[EMAIL PROTECTED] > > Subject:Re: proftpd issues > > > On Fri, 8 Aug 2003 [EMAIL PROTECTED] wrote: > > > Since having gotten xinetd working, I've shifted my effortst to the new > > proftpd. > > > > After another couple of hours of *pain* - I finally got it going in a > > limited fashion. > > > > First of all, I couldn't get it to start with the SYSTEM id as indicated > > in the proftpd.conf file. > > > > I had to use a custom ID added to the Administrators group and having the > > following User Rights assigned: > > > > "Act as part of the operating system" > > "Replace process level token" > > "Increase quotas" > > > > Question: Do these rights *have* to granted to the SYSTEM id for proftpd > > to work? > > Yes. Since you've as much as quoted from the ntsec userguide section, I'm > not going to bother citing a reference. The above rights are neede
Re: Win2k and cygwin memory leak
> And totally undoable. ?? Didn't I just read a few sentences earlier: > Apache, OTOH, is a SERVER, designed and implement to run continually in > the background. Forgive me if I'm mistaken, but isn't there a **CYGWIN DAEMON** project currently in the works Seems to little ole *clueless* me, such such issues could be addressed in that project. Seems like it'd be a heck of lot more congenial and productive to engage in creative "what if" scenario's about future developmemt possibilities than knee jerk character attacks. (Of course I realize that's more of a cygwin-app discussion - but it would certainly work well to placate us clueless types in the meantime.) I've made no demands, asked for no status, and set no deadlines. Just still *dumbfounded* at the "go tell it on the Microsoft" posturing. BK "Andrew DeFaria" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 11:28:18 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak [EMAIL PROTECTED] wrote: > Well, I can't feel too guilty about chiming "me too" - cause it > already brought forth a VERY useful and *productive* response: > > http://cygwin.com/ml/cygwin/2003-08/msg00460.html > > Unlike the ... uh-hem ... *posts* of some other folks This seems to me to be just a bandaid for a specific OS (not even one that you're running). > I will say this - anything that ends in "contact Microsoft" is about > as useful as a 300 baud modem on a Pentium 4. No - the modem is > definitely more useful. Hey it's tough, but what else can you do really if the OS hangs on to the memory? Bandaids like tweaking ini files and RAMpage are just that - bandaids. > All I want to do, is use Cygwin to solve some of my problems. So I'm > given a naked Compaq box with dual processors, 2 gigs of ram, and W2K > Server w SP3. ( I am not part of the "NT Team" at work - talking to > them is a lot like talking to Microsoft. ) I set up and run nothing > but cygwin and cygwin installed apps. And then I run it again, and > again and again and again - and then the box crashes. Again, why not install Linux? > And the NT people get all upset cause someone has to find the box in > the unlabeled server farm and power it down and back up again. Five > meetings full of name calling and finger pointing follow. > > Just a slice of my "clueless" life. > > But I digress. > > All I want is for software ( I didn't say *cygwin* - I'm being > *generic* ) to work as "expected". It's not "expected" for an application program to cleanup after an OS. > Crashing servers somehow violate reasonable expectations. It's not Cygwin that crashes the system - It's Windows. > There's an awful lot of other software out there that runs 24-7 on the > same windows that you wish to blame and *it* doesn't bring the box > down. Non-cygwin Apache comes to mind. I believe it's possible to > write code that doesn't as cfg put it "triggers a windows problem" > > Cause it certainly appears to me that others must have encountered the > same problem, and didn't say "well it's Microsoft's problem". You admittedly run processes that take up huge amounts of memory and then exit. It is the responsibility of the OS to free those resources when the process exits. Windows still has many acknowledged memory leaks in such situations. Apache, OTOH, is a SERVER, designed and implement to run continually in the background. Why don't you look at your own "cygwin" code and implement it as a deamon? > Now I'm not telling anyone what to do, or not to do. All I know is the > Microsoft installed base probably numbers in the *billions* out there. > And even if MS *were* to fix the problem, what are the odds that this > fix would find it's way onto even a sizable fraction of that base?? Depends on how many people insist and running 5 year old OSes (like Win 98)! > In spite of the bloated bombastic verbage often spewing forth from > this forum, a *cygwin* fix is > definitely the path of least resistance. And totally undoable. How many times must people tell you, when the application exits there is no possible way that Cygwin can do anything about it. Cygwin is not in the "business" like RAMPage. > Believe it or not. Someone will fix this someday. I have "faith". It > won't be me, and it won't be someone in Redmond Washington. I have a > work-around so I'm currently satisfied. I'll be patient. > > Cluelessly yours, > BK > > ( PS - I HATE Windows - put I get paid 'q
Re: proftpd issues - Got it WORKING
Jason, Here is the output when UNC home directory is in the passwd entry: NOTE: For security purposes the server the proftpd software is running on has been renamed to **SERVERNAME**. The Domain to **DOMAIN** and Remote Server to **REMOTESERVERNAME** and login id to **MYLOGINID**. passwd entry: **MYLOGINID**:unused_by_nt/2000/xp:48479:10513:Brian Kelly,U-**DOMAIN**\**MYLOGINID**,S-1-5-21-15 -888547495-1093625069-38479://**REMOTESERVERNAME**/users/**MYLOGINID**:/bin/bash Connected to **SERVERNAME**.**DOMAINNAME**.com. 220 ProFTPD 1.2.9rc1 Server (ProFTPD Default Installation) [**SERVERNAME**.**DOMAINNAME**.com] Name (localhost:**MYLOGINID**): 331 Password required for **MYLOGINID**. Password: 530 Login incorrect. ftp: Login failed. 421 Service not available, remote server has closed connection ftp> Attached is the strace. (See attached file: strace_output.txt) Hope this helps, Brian Kelly "Jason Tishler" <[EMAIL PROTECTED]>@cygwin.com on 08/11/2003 11:55:18 AM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: proftpd issues - Got it WORKING On Mon, Aug 11, 2003 at 11:27:33AM -0400, Igor Pechtchanski wrote: > Jason, do you think this inability to validate UNC paths stems from > proftpd prepending a "/" to the path or something? No, AFAICT, I have already address this problem in the following: http://bugs.proftpd.org/show_bug.cgi?id=2075 > I mean, Cygwin syscalls should be able to access the UNC path with no > problems... Agreed. > Is this worth investigating? I guess so, but I don't really have the "itch." Brian, would you be willing to help? What do you mean by "validate" in the following? > On Mon, 11 Aug 2003 Brian Kelly wrote: > > After doing an strace, I found that proftpd could not validate a > > home directory via UNC conventions. In the domain enviroment I'm > > working on, the domain account I'm using for testing has it's *home* > > directory on a network shared resource - and mkpasswd -d -u > > loginname created an entry with the home directory set to > > //servername/users/loginname. proftpd could *not* validate this and > > therefore exited without attempting any further authentication. What is the exact error message in proftpd's log file when the home directory is specified in UNC? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/11/2003 12:19:10 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement strace_output.txt 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: Win2k and cygwin memory leak
Well, I can't feel too guilty about chiming "me too" - cause it already brought forth a VERY useful and *productive* response: http://cygwin.com/ml/cygwin/2003-08/msg00460.html Unlike the ... uh-hem ... *posts* of some other folks I will say this - anything that ends in "contact Microsoft" is about as useful as a 300 baud modem on a Pentium 4. No - the modem is definitely more useful. All I want to do, is use Cygwin to solve some of my problems. So I'm given a naked Compaq box with dual processors, 2 gigs of ram, and W2K Server w SP3. ( I am not part of the "NT Team" at work - talking to them is a lot like talking to Microsoft. ) I set up and run nothing but cygwin and cygwin installed apps. And then I run it again, and again and again and again - and then the box crashes. And the NT people get all upset cause someone has to find the box in the unlabeled server farm and power it down and back up again. Five meetings full of name calling and finger pointing follow. Just a slice of my "clueless" life. But I digress. All I want is for software ( I didn't say *cygwin* - I'm being *generic* ) to work as "expected". Crashing servers somehow violate reasonable expectations. There's an awful lot of other software out there that runs 24-7 on the same windows that you wish to blame and *it* doesn't bring the box down. Non-cygwin Apache comes to mind. I believe it's possible to write code that doesn't as cfg put it "triggers a windows problem" Cause it certainly appears to me that others must have encountered the same problem, and didn't say "well it's Microsoft's problem". Now I'm not telling anyone what to do, or not to do. All I know is the Microsoft installed base probably numbers in the *billions* out there. And even if MS *were* to fix the problem, what are the odds that this fix would find it's way onto even a sizable fraction of that base?? In spite of the bloated bombastic verbage often spewing forth from this forum, a *cygwin* fix is definitely the path of least resistance. Believe it or not. Someone will fix this someday. I have "faith". It won't be me, and it won't be someone in Redmond Washington. I have a work-around so I'm currently satisfied. I'll be patient. Cluelessly yours, BK ( PS - I HATE Windows - put I get paid 'quite well' to work on it, and given the current state of the economy - I think I'll keep working on it . ) "Andrew DeFaria" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 06:24:26 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak [EMAIL PROTECTED] wrote: > It would have been "nice" if there was an acknowledgement of this > problem (cygwin's or not) rather than attempted character assassinations. It has already been acknowledged several times over that it is not a problem of Cygwin's rather a problem of Windows. What else do you want? When you cluelessly continue to assert that it's a Cygwin memory leak is exactly where is leads down the path to character assassinations. (BTW: Ever think of replacing that Windows box with just a Linux box?) -- 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/ "WellChoice, Inc." made the following annotations on 08/07/2003 09:49:40 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
Mysterious FTP failure
I’ve been using cygwin’s ftp.exe client program on my NT 4.0 SP 6 machine for quite a while. It’s worked flawlessly for months. I have not made any changes to the box and have not upgraded any cygwin components in months. Sometime in the last 48 hours “something” changed. Now when I attempt to ftp a tar file, it sends about 98-99% of it or so, and then mysteriously quits – “thinking” it had sent the whole thing. (It does not report any transmission errors). It’s not tar, because if I ftp TO the box via inetd/ftpd and retrieve the file – the whole thing transfers just fine. I’ve rebooted the box numerous times, as well cold shutdown (to reset the network card) – same problem. I haven’t tried uninstalling or reinstalling any cygwin components, because I’d really like to understand what’s CAUSING the problem. I’m writing automation software that has advanced error checking and I’d like to trap and “identify” this condition (if possible) and advise in an error message what the possible genesis of the condition is and what hints one can follow to remedy and/or prevent the problem. The automation software essentially “automates” cross-network unix command-line environments and is 100% perl. As such, it relies on cygwin for this environment on MSWin boxes. If one “node” fails – it can switch boxes automatically – but being able to determine WHY a box has a problem and reporting it successfully is VERY important to the overall approach of the software.  If anyone’s got a clue what’s happened to break ftp – or can suggest what other things I can investigate to get the “bottom” of this problem – I’d REALLY appreciate it.  Brian Kelly -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Mysterious FTP failure
After a bit of investigation - I've narrowed down some of the parameters of the problem. First of all the problem appears to exist only on NT4.0 - not W2K. Second, it only exists if one first telnets to the NT4.0 box and THEN invokes ftp and sends a file. If I use ftp from a LOCAL bash shell, the file transfers just fine. (The problem also exists it one telnets to the box FROM the box - i.e. - a remote connection is NOT necessary). Furthermore, my memory indeed failed me. I did upgrade to the latest version of cygwin, cygwin dll's, and inetutils since the time I last had this working - about a month or so ago. Prior to that I had not upgraded for about four or five months (or more). SO THERE WAS A CHANGE ON MY NT BOX - AND THE CHANGE WAS A NEW VERSION OF CYGWIN AND INETUTILS. What threw me off, was the fact that I had not attempted to ftp FROM A REMOTE CONNECTION since the upgrade. All the ftp's I did, I did from a local bash shell - which works just fine. Of course none of this "proves" that the problem lies with new cygwin code. If anyone running NT 4.0 SP 6 could try to recreate the problem as described above - that would be a big help. Brian Kelly > RE: Mysterious FTP failure > From: "lhall at pop dot ma dot ultranet dot com" dot com> > To: reedfish at ix dot netcom dot com, cygwin at cygwin dot com > Date: Thu, 19 Dec 2002 10:34:48 -0500 > Subject: RE: Mysterious FTP failure > Reply-to: lhall at rfk dot com > > I'm guessing that you're stuck debugging this one. I don't think > someone else is going to be able to guess what changed on your > system to cause this problem to surface for you (though maybe I'm > wrong). I expect the most direct route to discover more details > about the problem and an eventual solution would be to run a > debug version of ftp in gdb and see what happens. This should at > least narrow down the possibilities to a reasonable size and give > the list some details to cogitate, assuming the results don't > automatically point you to a solution yourself. > Good luck, > Larry > Original Message: > - > From: Brian Kelly [EMAIL PROTECTED] > Date: Thu, 19 Dec 2002 09:15:53 -0500 > To: [EMAIL PROTECTED] > Subject: Mysterious FTP failure > I've been using cygwin's ftp.exe client program on my NT 4.0 SP 6 > machine for quite a while. It's > worked flawlessly for months. I have not made any changes to the box and > have not upgraded any > cygwin components in months. Sometime in the last 48 hours "something" > changed. Now when > I attempt to ftp a tar file, it sends about 98-99% of it or so, and then > mysteriously quits "thinking" > it had sent the whole thing. (It does not report any transmission > errors). It's not tar, because if I > ftp TO the box via inetd/ftpd and retrieve the file the whole thing > transfers just fine. I've rebooted the > box numerous times, as well cold shutdown (to reset the network card) > same problem. I haven't > tried uninstalling or reinstalling any cygwin components, because I'd > really like to understand what's > CAUSING the problem. I'm writing automation software that has advanced > error checking and I'd > like to trap and identify this condition (if possible) and advise in > an error message what the possible > genesis of the condition is and what hints one can follow to remedy > and/or prevent the problem. The > automation software essentially automates cross-network unix > command-line environments and is > 100% perl. As such, it relies on cygwin for this environment on MSWin > boxes. If one node fails it > can switch boxes automatically but being able to determine WHY a box > has a problem and reporting > it successfully is VERY important to the overall approach of the > software. > If anyone's got a clue what's happened to break ftp or can suggest > what other things I can investigate > to get the bottom of this problem I'd REALLY appreciate it. > Brian Kelly "Empire Health Choice Inc." made the following annotations on 12/21/2002 10:04:00 AM -- [INFO] -- Access Manager: Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please rep
RE: Mysterious FTP failure - more info
I did a further test to verify the existence of the problem. I did the following from a locally invoked bash shell [ for security - I "starred" out the hostname ]. I transferred the file via ftp from the local box TO the local box into a sub-directory. The same behavior exists if the file is transferred to another box : bmk1n0@*** ~ - telnet localhost Trying 127.0.0.1... Connected to *.*.com. Escape character is '^]'. CYGWIN_NT-4.0 1.3.16(0.65/3/2) (*) (tty0) login: bmk1n0 Password: This is *. bmk1n0@ ~ - ftp localhost Connected to *.**.com. 220- 220- 220 FTP server (GNU inetutils 1.3.2) ready. Name (localhost:bmk1n0): bmk1n0 331 Password required for bmk1n0. Password: 230- This is . 230 User bmk1n0 logged in. ftp> !pwd /cygdrive/c/temp ftp> lcd /cygdrive/c/provider Local directory now /cygdrive/c/provider ftp> cd /cygdrive/c/provider/crap 250 CWD command successful. ftp> bin 200 Type set to I. ftp> put prov.tar 200 PORT command successful. 150 Opening BINARY mode data connection for 'prov.tar'. 226 Transfer complete. 43872750 bytes sent in 5.26 seconds (8343999 bytes/s) <=== BYTES TRANSFERRED ftp> !ls -l total 55768 drwxrwxrwx2 bmk1n0 None0 Dec 21 10:19 crap -rwxrwxrwx1 bmk1n0 None 44113920 Dec 8 20:40 prov.tar <===ACTUAL SIZE drwxrwxrwt5 bmk1n0 None 4096 Dec 8 20:36 provider drwxrwxrwt4 bmk1n0 None 4096 Dec 8 20:33 servlets -rwxrwxrwx1 bmk1n0 None 12984320 Dec 8 20:42 static.tar drwxrwxrwt 3 bmk1n0 None0 Dec 8 20:33 web ftp> Brian Kelly Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: Mysterious FTP failure After a bit of investigation - I've narrowed down some of the parameters of the problem. First of all the problem appears to exist only on NT4.0 - not W2K. Second, it only exists if one first telnets to the NT4.0 box and THEN invokes ftp and sends a file. If I use ftp from a LOCAL bash shell, the file transfers just fine. (The problem also exists it one telnets to the box FROM the box - i.e. - a remote connection is NOT necessary). Furthermore, my memory indeed failed me. I did upgrade to the latest version of cygwin, cygwin dll's, and inetutils since the time I last had this working - about a month or so ago. Prior to that I had not upgraded for about four or five months (or more). SO THERE WAS A CHANGE ON MY NT BOX - AND THE CHANGE WAS A NEW VERSION OF CYGWIN AND INETUTILS. What threw me off, was the fact that I had not attempted to ftp FROM A REMOTE CONNECTION since the upgrade. All the ftp's I did, I did from a local bash shell - which works just fine. Of course none of this "proves" that the problem lies with new cygwin code. If anyone running NT 4.0 SP 6 could try to recreate the problem as described above - that would be a big help. Brian Kelly > RE: Mysterious FTP failure > From: "lhall at pop dot ma dot ultranet dot com" > To: reedfish at ix dot netcom dot com, cygwin at cygwin dot com > Date: Thu, 19 Dec 2002 10:34:48 -0500 > Subject: RE: Mysterious FTP failure > Reply-to: lhall at rfk dot com > > I'm guessing that you're stuck debugging this one. I don't think > someone else is going to be able to guess what changed on your > system to cause this problem to surface for you (though maybe I'm > wrong). I expect the most direct route to discover more details > about the problem and an eventual solution would be to run a > debug version of ftp in gdb and see what happens. This should at > least narrow down the possibilities to a reasonable size and give > the list some details to cogitate, assuming the results don't > automatically point you to a solution yourself. > Good luck, > Larry > Original Message: > - > From: Brian Kelly [EMAIL PROTECTED] > Date: Thu, 19 Dec 2002 09:15:53 -0500 > To: [EMAIL PROTECTED] > Subject: Mysterious FTP failure > I've been using cygwin's ftp.exe client program on my NT 4.0 SP 6 > machine for quite a while. It's > worked flawlessly for months. I have not made any changes to the box and > have not upgraded any > cygwin components in months. Sometime in the last 48 hours "something" > changed. Now when > I attempt to ftp a tar file, it sends about 98-99% of it or so, and then > mysteriously quits "thinking" > it had sent the whole thing. (It does not report any transmission > errors). It's not tar, because if I > ftp TO the box via inetd/ftpd and retrieve the file the whole thing > transfers just fine. I&#
Re: Bug in rm -r with locked files
YES! I too concur BIG TIME! In fact, I do not use rm -r in my scripts because of this problem. In perl scripts I use the Windows command $output=`cmd /c del /s *.* > 2>&1` (or similar) and examine the output for ACCESS DENIED, where I can then do an attrib and continue. AN . since we're on the topic of rm I have spent a limited amount of time trying to isolate a NASTY memory leak in NT4.0 SP6 when running commands via telnet. I have 512 MB of ram and if do a lot of rm's or ls -sh over a telnet connection, I can actually deplete the memory till the box locks - usually in as little as 20 minutes. I haven't reported this problem till now because without more specifics, my experience has been that such posts usually end up being ignored. And specifics take time and effort to isolate and enumerate. But, since rm is the topic, I thought I'd piggy-back this issue in case someone actually does take the time to poke around the source code. In that vein, I've attached an "overlooked" (or ignored - I expect a "MEAN" response for this - so FIRE AWAY! \\-> ((o)) ;-) ) post from the archives that addresses an rm memory leak. I tested it a couple of days ago and YEP - it's still there!!! Brian Kelly ### > memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000)) > From: "Reddie, Steven" > To: cygwin at cygwin dot com > Date: Thu, 28 Feb 2002 15:30:26 +1100 > Subject: memory leak? (was: 1.3.9: "fork: Permission denied" (Windows 2000)) > > There's a memory leak, but I can't work out what is causing it. None of the > processes in Task Manager own up to it, so does that mean it's the OS? > I have been able to reproduce this leak using the scripts included below. > mkfiles creates 1000 files. rmfiles removes those 1000 files. Executing > mkfiles results in about 5MB being leaked, whilst rmfiles leaks about 30MB > each time. Below are stats from the Performance tab of Task Manager whilst > running these scripts. Handles don't seem to be leaked. > It takes about 4 seconds to create the 1000 files, but about 70 seconds to > remove those 1000 files. Does this seem normal? > TimeHandles, Available Physical Memory, Total Commit Charge > 2:003870, 149.4M, 95.9MBefore running mkfiles > 2:053719, 143.1M, 97.5MBefore running rmfiles > 2:103679, 115.4M, 125.4MBefore running mkfiles > 2:153673, 110.4M, 130.0MBefore running rmfiles > 2:203661, 80.7M, 159.6MBefore running mkfiles > 2:253689, 76.5M, 163.6MBefore running rmfiles > 2:303686, 49.4M, 191.1MBefore running mkfiles > 2:353718, 44.9M, 194.1MBefore running rmfiles > ./rmfiles: line 5: 30312 Segmentation fault (core dumped) rm -f > files/file$a > 2:373717, 16.3M, 222.6MAfter running rmfiles > After this, I ran each of the commands again. rmfiles failed with an error > message simiar to the following. This following error message was displayed > when trying to open a new bash window after this failure: > 0 [main] bash 28900 sync_with_child: child 37868(0x1A8) died before > initialization with status code 0x80 >6476 [main] bash 28900 sync_with_child: *** child state waiting for > longjmp > bash: fork: Resource temporarily unavailable > This appears to be the same problems as I was getting whilst doing a > recursive make. > NOTE: I don't get this problem on my desktop, only on the notebook, but then > I was only getting the recursive make problem on the notebook. If anyone > out there is also having the recursive make or "fork: Permission denied" > problems could you please try running these scripts and watching the stats > in the Performance tab of Task Manager. It would be good to know if this is > just me (maybe corrupt Windows 2000), or a more common problem. > Regards, > Steven > mkfiles > === > #!/bin/bash > mkdir files > for ((a=0; a<1000; a++)) do > echo foo > files/file$a > done > rmfiles > === > #!/bin/bash > for ((a=0; a<1000; a++)) do > rm -f files/file$a > done > rmdir files ## > Yep, I concur. If windows has a lock on the file, rm just hangs. I've > seen it hang on directories when doing an 'rm -rf yada/*" >> On Tue, 2003-01-21 at 06:50, Gael Mulat wrote: >> Hi, >> >> This is a bug report about rm (package fileutils, version 4.1-1) on W2K. >> >> Test case: take 2 cygwin shells. >> shell 1: >>
Re: Bug in rm -r with locked files
Interesting - It's more important to "force" a square into a circle and uphold a "standard" than it is to deliver common sense "usability". MSWin is inherently "UN-posix" by nature, and while I applaud trying to make a "silk (posix) purse" out of it, if it means rendering the most basic of utilities fundamentally unusable - then what is the point??? As I posted earlier, I cannot use rm -rf in a script and must resort to the native "del" cmd because rm -rf hangs when it encounters a locked file. Most of the files can be recovered with either attrib or chmod xxx * and then the script can continue. But in order for that to happen, there has to be an ERROR MSG - something I can get from the MS del cmd - even though I'd rather use rm. It's all lost on me ... Brian Kelly "Randall R Schulz" <[EMAIL PROTECTED]>@cygwin.com on 01/21/2003 02:25:19 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Bug in rm -r with locked files Shankar, At 11:05 2003-01-21, Shankar Unni wrote: >[EMAIL PROTECTED] wrote: >>You may find the 'handle' utility from www.sysinternal.com a handy >>(no pun intended :-) ) tool for determining which files are opened >>by which processes. > >I don't think that was the primary issue. The issue was that if a process >is using a directory as its working directory (chdir()'ed into it), "rm >-rf" goes into an infinite loop attempting to remove the directory (rather >than print an error and move on). > >Definitely a bug, and still a bug. That, in fact, is a presumption. The Cygwin principals are aware of this behavior and it is not new. It is a trade-off required to get POSIX-like behavior from the "unlink" system call as emulated by Cygwin. Please review the discussions under the subject "Infinite Loop In "rm -fr" When Busy File Encountered" on April 6, 2002 and "REPOST: unlink semantics" from April 10, 2002. I'm not an expert, but this has come up more than once (I initiated the April 6 round of discussions) and the upshot is that given the mismatch of API semantics between Windows and POSIX, this is the best that can be done. Randall Schulz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "Empire Health Choice Inc." made the following annotations on 01/21/2003 02:43:30 PM -- [INFO] -- Access Manager: Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bug in rm -r with locked files
Well - even so "my" problem remains The scripts that I have are
written to work cross-platform,
and because I can't use rm -rf when telneting to a cygwin box with an
automated telnet/ssh script,
I have to do this nonsense:
if ($telnet_handle->{$hostlabel}->{OS} eq 'cygwin') {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c del /s
$dir");
} else {
($stdout,$stderr)=$telnet_handle->{_cmd_handle}->cmd("cmd /c rm -r
$dir");
}
I'd rather not have to do this!!
Brian
"Shankar Unni" <[EMAIL PROTECTED]>@cygwin.com on 01/21/2003 02:47:54
PM
Sent by:[EMAIL PROTECTED]
To:"'Max Bowsher'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc: (bcc: Brian Kelly/WTC1/Empire)
Subject:RE: Bug in rm -r with locked files
Max corrected me:
> No. The thing that rm -rf gets stuck on is vim .swp recovery file.
Ah. Sorry. Should have straced the thing before shooting off.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
"Empire Health Choice Inc." made the following
annotations on 01/21/2003 03:00:42 PM
--
[INFO] -- Access Manager:
Attention! This electronic message contains information that may be legally
confidential and/or privileged. The information is intended solely for the individual
or entity named above and access by anyone else is unauthorized. If you are not the
intended recipient, any disclosure, copying, distribution, or use of the contents of
this information is prohibited and may be unlawful. If you have received this
electronic transmission in error, please reply immediately to the sender that you have
received the message in error, and delete it. Release/Disclosure Statement
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Bug in rm -r with locked files
Except when you're dealing with more than 10,000 files on a fortune 1000 web portal. Chmoding the whole thing imposes an "oppressive" delay. Darn - hey boss - where's that $300,000 you promised me for commercial deployment software What? - you'll talk to me after you get done laying off my co-worker? OH ... OKAY! Brian Kelly "Steve Fairbairn" <[EMAIL PROTECTED]>@cygwin.com on 01/22/2003 03:57:00 AM Sent by:[EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:RE: Bug in rm -r with locked files Just a small suggestion, but in order to avoid this problem and keep cross platform compatibility, could you not recursively chmod the files first, then use rm -r (which someone else stated isn't affected) to remove the files. Means the tree has to be parsed twice, but should produce the required results? Steve. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Subject: Re: Bug in rm -r with locked files use rm -rf in a script and must resort to the native "del" cmd because rm -rf hangs when it encounters a locked file. *** This email has originated from Perwill plc (Registration No. 1906964) Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK Tel: +44 (0)1420 545000 Fax: +44 (0)1420 545001 www.perwill.com *** Privileged, confidential and/or copyright information may be contained in this email, and is only for the use of the intended addressee. To copy, forward, disclose or otherwise use it in any way if you are not the intended recipient or responsible for delivering to him/her is prohibited. If you receive this email by mistake, please advise the sender immediately, by using the reply facility in your email software. We may monitor the content of emails sent and received via our network for the purposes of ensuring compliance with policies and procedures. This message is subject to and does not create or vary any contractual relationships between Perwill plc and the recipient. *** Any opinions expressed in the email are those of the sender and not necessarily of Perwill plc. *** This email has been scanned for known viruses using McAfee WebShield 4.5 MR1a *** -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "Empire Health Choice Inc." made the following annotations on 01/22/2003 06:45:33 AM -- [INFO] -- Access Manager: Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in rm -r with locked files
Yea yea yea - I know I know. I'm just bitchen to bitch. Problem is already solved - MS del works just fine - it's just "Kludgy" is all. I'll wait till someone gets around to it. ME?? Oh hey, I'm just a "Perl" guy!! The only thing I've written in c is "hello world". Plus I have NO time to learn c "and" trouble-shoot a nasty problem. Would probably take me 3 to six months - and I'm workin 70-80 hour weeks as it is. Am I grateful to those who "DO" know? SURE OF COURSE. So in case anyone wants to accuse me of being a feeloading good-for-nothing ingrate - I say this: THANK YOU THANK YOU THANK YOU 1000 THANK YOU X 1000 There ... feel better? Hmmm ... though not ... ; - ) Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 01/22/2003 10:38:02 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Bug in rm -r with locked files On Wed, Jan 22, 2003 at 06:44:13AM -0500, [EMAIL PROTECTED] wrote: >Except when you're dealing with more than 10,000 files on a fortune >1000 web portal. Chmoding the whole thing imposes an "oppressive" >delay. > >Darn - hey boss - where's that $300,000 you promised me for commercial >deployment software What? - you'll talk to me after you get done >laying off my co-worker? OH ... OKAY! How about you give me $150,000 and I'll solve the problem for you? Either that or come up with a patch to fix the problem. Sadly, free software doesn't mean "works perfectly or your problem gets fixed for free". Quite the contrary, it gives *you* the freedom to modify the source to fix problems. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "Empire Health Choice Inc." made the following annotations on 01/22/2003 11:07:41 AM -- [INFO] -- Access Manager: Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: idea for a new project, libntcmd
Boy I just don't GET IT!! Anyone who wants to use ANY cmd.exe command, including start just needs to use cmd /c ANY-WINDOWS-CMD-COMMAND-HERE HOW EASY IS THAT? Maybe adding this insight to the FAQ might be helpful - for those who FAIL to read the SIMPLE output from cmd /? ... Of course - will such people read the FAQ "BEFORE" bothering the busy folks on this list NOT!!!!! Brian Kelly PS (One can also use cmd /c to run CYGWIN utilities - even something like cmd /c start cmd /c rm -rf * which will run as separate process enabling you to return to the command line. VERY COOL - for those who READ DOCUMENTATION!! Of course - we didn't mention "fork" ... Windows folks eat with their hands - primitive savages that they are ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Max Bowsher Sent: Friday, January 24, 2003 7:02 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: idea for a new project, libntcmd Rafael Kitover wrote: >>> 2) support cmd.exe builtins like del/copy/exists/etc, and execute >>> dos batch files. Things like if and goto, because they're only >>> useful in batch, would present little problem as well. >> >> Yuk! Why? > > Often when I go between cmd and zsh, I get my copy/cp del/rm mixed up. > This would also apply to folks who have to use both the unix and > windows command lines on a regular occasion. Solution: Don't use cmd ;-) No, seriously, wouldn't shell aliases and/or stub .exes or batch files give you most of this functionality *right now*? > Also to support simple > Makefiles, batch files etc. in various packages. I have to ask: Why try to coerce a makefile designed for a cmd.exe shell into running with bash? > Making aliases or shell functions would not work well, because those > are not propagated to subprocesses. Aliases, no, unless you put them in your shell's startup file. In bash at least, you can 'export -f' functions. >>> This would allow better interaction between the windows and cygwin >>> worlds, and also be convenient for windows users new to unix. >> >> Really? Or would it simply delay them learning the knowledge to >> function in >> an environment that does not make specific allowances for them? > > Well, the goal would be for new cygwin users, who often have little > knowledge of UNIX, to have more space to get comfortable in learning > the environment. Chris answered this perfectly. Anyway, a compatibility package of shell scripts or stub exes ought to be easy to acheive, and has the advantage of working with all shells. >>> It should also allow for running windows makefiles >>> as-is. >> >> This feels more like MSYS territory than Cygwin. > > This would be useful for MSYS, which is a fork of Cygwin too of > course. We don't want MSYS to diverge too greatly, especially since > Cygwin is a perfectly functional environment for building mingw > programs. Define "We" ;-) >>> Thoughts? Is this interesting/crazy/impossible? >> >> Well, you're getting a biased opinion here - I hate cmd. But I think >> this >> has 2 flaws: >> >> 1) You want to make bash play nice with Windows paths - what about >> all those >> supplementary tools that makefiles often invoke? > > If a makefile uses visual studio or borland tools, we'd assume the > user has those installed and in their paths. Perhaps some simple > wrappers for some visual studio command line tools could also be made > to use the cygwin equivalents. But then why does this makefile want to run under Cygwin make and bash?? Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: kudos!
Does this mean that Cygwin is not ready for production?? Darn!! and I was just getting ready to roll it out to my biggest client - Randy's Pizza and Bait. ( sorry - not realation ) Brian Kelly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Randall R Schulz Sent: Saturday, February 15, 2003 9:22 PM To: [EMAIL PROTECTED] Subject: Re: kudos! Alec, There appears to have been an error in the delivery your message. All that got through was a simple thank-you and a compliment. Apparently lost in the transmission of your message was the part following the complimentary thank-you in which you complain about the idiotic way in which file permissions are handled, the blatant failure of the "login" and "su" commands, the non-standard tty signal handling and dozens of other not-too-small defects that collectively show that the Cygwin engineers (so-called) know nothing about security, Unix, Windows, C/C++ or probably even what a Turing machine is. Also missing was the incontrovertible and unambiguous evidence of Cygwin's utter shoddiness displayed by your perfectly functional Linux software whose compilation under Cygwin causes the seriously mis-configured GCC compiler to emit thousands of diagnostics and how after you managed to squelch them all, the resulting executable not only crashes immediately after being invoked but also causes Cygwin to bring your system down with a BSOD. Could you resend please? We prefer HTML mail with lots of embedded screen shots in BMP format that depict the multifarious defects in graphic detail for all the world to see. Thanks. We'll all feel better when we get that. Randall Schulz At 18:05 2003-02-15, Alec Effrat wrote: >Just wanted to drop a note... kudos on a great thing for those of us >enslaved on a wintendo. > > > > >-- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Net::Telnet needs line of code added for fhopen to work withcygwin-perl and IO::Pty module in MSWin
Hi Jay,
My name is Brian Kelly, and I've been working with your Net::Telnet module
for over 4
years. First I'd like to say THANKS It's been a fabulous tool for me - as
I'm sure it has for
thousands upon thousands of folks around the globe.
Lately I've been writing an automation wrapper that relies very heavily on
your module.
With the recent evolution of the Cygwin Unix layer for MSWin operating systems,
telneting to a
Windows box is now easy, robust and FRE!!. New possibilities are now opening
up to truly
integrate whole networks with a common set of scripts and tools that use telnet,
ftp, and ssh as
a means of communicating. Of course, with the fabulous documentation provided by
Lincoln
Stein in his book "Network Programming with Perl", I'm sure there are many like
myself who
are working in this direction with heterogenius environments.
Recently, the IO:Pty module was successfully ported to work with
cygwin-perl. Now it
is truly possible to use your fhopen method (per Lincoln Stein's chapter on your
Telnet module)
to do Expect-like control of interactive programs using your Telnet module on
MSWin OS's.
There's just one slihhht problem ...
It seems that on a MSWin OS there is no way to truly escape the infamous
CR\LF.
In your "print" subroutine, you "attempt" to do this with the following
line of code:
sub print {
my ($self) = shift;
my (
$data,
$endtime,
$fh,
$len,
$nfound,
$nwrote,
$offset,
$ready,
$stream,
$timed_out,
$timeout,
);
$stream = *$self->{net_telnet};
$stream->{timedout} = '';
$stream->{num_wrote} = 0;
return $self->error("print failed: handle is closed")
unless $stream->{opened};
## Try to send any waiting option negotiation.
if (length $stream->{unsent_opts}) {
&_flush_opts($self, $stream);
}
## Add field and record separators.
$data = join($stream->{ofs}, @_) . $stream->{ors};
## If requested, log the output.
if ($stream->{outputlog}) {
local $\ = '';
$fh = $stream->{outputlog};
$fh->print($data);
}
## Escape TELNET IAC and carriage-return chars.
if ("\n" ne "\015") { # not running on a Mac
if ($stream->{telnet_mode}) {
# $data =~ s(\377)(\377\377)g;
$data =~ s(\015)(\015\000)g;
}
if (!$stream->{bin_mode}) {
$data =~ s(\n)(\015\012)g;<===Here
is where you attempt to escape the CR
chomp $data;
<-- This is the code I had to add to achieve correct
results
}
}
else { # probably running on a Mac
The automation wrapper I'm working on is a module I am hoping
to release to the CPAN within six months to a year. But aside from my "selfish"
desires, it would seem that more people as time goes by are going to run into
this issue. ( I may not even be the first! )
Without doing that chomp on the end of the line, when attempting to use
fhopen
to automate a login sequence, the CR\LF prevents an opportunity to pause the
password
prompt and interprets that CR\LF as a null password - of course causing failure.
By
chomping off the CR, the proper and "expected" behavior is achieved.
This solution may indeed be "too simple". There may be other issues that
must
be considered in arriving at a "final solution". Anyway - I needed to bring it
to your
attention. If you are no longer maintaining this module, could you tell me who
is?
Again, thanks for making my computing life A LOT EASIER!!!
Sincerely,
Brian Kelly
Work Phone: 212-286-3931
Pager: 810-450-9766
"Empire Blue Cross Blue Shield" made the following
annotations on 02/26/02 19:33:28
--
[INFO] -- Access Manager:
Attention! This electronic message contains information that may be legally
confidential and/or privileged. The information is intended solely for the individual
or entity named above and access by anyone else is unauthorized. If you are not the
intended recipient, any disclosure, copying, distribution, or use of the contents of
this information is prohibited and may be unlawful. If you have received this
electronic transmission in error, please reply immediately to the sender that you have
received the message in error, and delete it.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Win2k and cygwin memory leak
> Looking at RAMpage's code and reading the description, I see nothing > that indicates it would solve this supposed "memory leak" problem. All > that it does is allocate a huge chunk of memory and free it, forcing any > fragmented memory out onto disk. I really don't see how that would > cause any improvement in anything related to a memory leak. I do not know much, but I do know this. With RAMpage running 4 times a day, my server stays up. Without it, it crashes. The only thing running on the box other than the naked OS and backup software and Anti-virus, is cygwin and cygwin installed apps. I agree with you to the extent that it certainly doesn't *solve* the *supposed* memory leak problem. But it keeps my server up and I'm sure it will help others too. BK "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 10:48:57 PM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Fri, Aug 08, 2003 at 03:44:11AM +0200, Luc Hermitte wrote: >* On Thu, Aug 07, 2003 at 03:24:26PM -0700, Andrew DeFaria <[EMAIL PROTECTED]> wrote: >>It has already been acknowledged several times over that it is not a >>problem of Cygwin's rather a problem of Windows. > >I think we all agree to that. But unfortunatelly, so far, only Cygwin >seems affected by that problem. You're referencing facts not in evidence. We don't know that it is only Cygwin. I haven't seen any evidence that anyone has done any research on this. We don't know that this isn't triggered by something as simple as a virus checker. >> When you cluelessly continue to assert that it's a Cygwin memory leak >> is exactly where is leads down the path to character assassinations. > >Could we say that cygwin relies on a faulty library developped by >Microsoft ? And that nobody has identified the faulty library ? Saying this would be pure speculation. Just as an observation: I went to the RAMpage home page and, curiously, it does not prominently mention cygwin. In fact, I couldn't find a mention of cygwin at all. If this was a problem that only manifested with cygwin programs, I would think that RAMpage would mention that fact. Looking at RAMpage's code and reading the description, I see nothing that indicates it would solve this supposed "memory leak" problem. All that it does is allocate a huge chunk of memory and free it, forcing any fragmented memory out onto disk. I really don't see how that would cause any improvement in anything related to a memory leak. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/08/2003 09:34:38 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
-- Forwarded by Brian Kelly/WTC1/Empire on 08/07/2003 10:07 PM --- Brian Kelly 08/07/2003 10:06 PM To:"Luc Hermitte" <[EMAIL PROTECTED]> cc: Subject:Re: Win2k and cygwin memory leak (Document link: Brian Kelly) *You're Welcome* For it *I* the *clueless* (cfg's pet name for me) one who has brought the gift of RAMpage to the cygwin world. (Many thanks to J. Fitz who wrote it!). I will post in a couple of days a perl script that you can then use with cron and RAMpage that will enable you to use Cygwin "reboot free". As it "ought" to be. Brian Kelly "Luc Hermitte" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 09:44:11 PM Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak * On Thu, Aug 07, 2003 at 03:24:26PM -0700, Andrew DeFaria <[EMAIL PROTECTED]> wrote: > It has already been acknowledged several times over that it is not a > problem of Cygwin's rather a problem of Windows. I think we all agree to that. But unfortunatelly, so far, only Cygwin seems affected by that problem. Hence, every now and then, the question will be asked on this list. Because this is an extremly annoying bug that we have very little chance to run into if we are not using Cygwin. I guess cygwin is using a library not always correctly implemented. "Isn't there any workaround cygwin could use ? " is a typical question for many of us. > What else do you want? Personnally, I hope, as the question will be raised again and again, that an expertise will emerge. Just knowing why there is a problem will be a big step ahead -- ie: which library/service pack/... is faulty. This time, someone told us about a freeware that collects "forgotten" memory. Many thanks to him! If, thanks to this program, I will be able to run ./configure for mutt or run my computer for more than 2 days (or 2 hours) without the need to reboot ... you have no idea of how glad I will be. That kind of answer is want we expect. That is not a definitive bug fix, but a possible workaround. BTW, if this program is an effective workaround, I think this will merit a topic in the FAQ. > When you cluelessly continue to assert that it's a Cygwin memory leak > is exactly where is leads down the path to character assassinations. Could we say that cygwin relies on a faulty library developped by Microsoft ? And that nobody has identified the faulty library ? -- Luc Hermitte PS: don't mistake me, Cygwin is a wonderful project. And I thank people like Christopher who work so hard on 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/ "WellChoice, Inc." made the following annotations on 08/07/2003 10:09:35 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Win2k and cygwin memory leak
Forgot to add that I call the perl script every *FIVE* minutes - 24-7. The script is VERY memory intensive so it really works cygwin and the 2000 Server HEAVY. If I didn't scrub the memory four times a day, the box would crash - and did just recently when I had turned off RAMpage for testing. Brian Kelly [EMAIL PROTECTED]@cygwin.com on 08/07/2003 12:52:53 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak Now seems to be a good time for me to jump in. I can DEFINITIVELY say that *something* within cygwin - or perl (using Cygwin's perl) - causes a very real and very measurable memory leak. I run a 24-7 automated FTP encryption architechture using cygwin cron which launches a perl script that automates telnet and ftp from the inetutils package. After each invocation, memory is lost. The only thing that keeps the box from dying completely is that in the very same crontab I call - four times a day - a memory manager called *RAMpage* which is also open source and can be invoked from the command line. This program frees up the lost memory allowing me to essentially run the server indefinitely. I would of course rather not have to use RAMpage at all - but since there's ongoing denial about the existence of "memory leaks" *somewhere* in the vastness of cygwin - I have no choice but to resort to that which *works*. Ah well, someday the denial will end, or the problem will get fixed unintentionally when some other change is made and the "cygworld will go on". In the meantime, I have a solution - kludgy you can be sure - but it works and has been doing so for nearly nine months. RAMpage => http://www.jfitz.com/software/RAMpage/ Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/07/2003 11:40:57 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Win2k and cygwin memory leak On Thu, Aug 07, 2003 at 11:32:42AM -0400, Rolf Campbell wrote: >This may be a Win2000 problem, not a cygwin problem...What service pack >are you running? "May be"? You run a bunch of programs, exit them, and Windows slowly loses memory after each exit? Hard to see how that's a cygwin problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/07/2003 12:55:14 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/ "WellChoice, Inc." made the following annotations on 08/07/2003 01:02:16 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
No output from DOS commands via telnet using xinetd
I've noticed that running most DOS commands via telnet using *xinetd* produced no output. Runing DOS commands via telnet using *inetd* works as expected and DOES produce the expected output. For instance, in telnet via inetd, typing: net help produces the following output: - [EMAIL PROTECTED] ~ - net help The syntax of this command is: NET HELP command -or- NET command /HELP Commands available are: NET ACCOUNTS NET HELP NET SHARE NET COMPUTER NET HELPMSG NET START NET CONFIG NET LOCALGROUPNET STATISTICS NET CONFIG SERVERNET NAME NET STOP NET CONFIG WORKSTATION NET PAUSE NET TIME NET CONTINUE NET PRINT NET USE NET FILE NET SEND NET USER NET GROUPNET SESSION NET VIEW NET HELP SERVICES lists the network services you can start. NET HELP SYNTAX explains how to read NET HELP syntax lines. NET HELP command | MORE displays Help one screen at a time. [EMAIL PROTECTED] ~ - --- In telnet via xinetd, their is NO output from the same command: --- [EMAIL PROTECTED] ~ - net help [EMAIL PROTECTED] ~ - --- Also, if you run a DOS shell via telnet through inetd, you can see the output of unix/cygwin commands: [EMAIL PROTECTED] ~ - cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. e:\temp>pwd pwd /cygdrive/e/temp e:\temp>exit exit [EMAIL PROTECTED] ~ Output of same pwd command when run via telnet through xinetd: [EMAIL PROTECTED] ~ - cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. e:\temp>pwd pwd e:\temp>exit exit [EMAIL PROTECTED] ~ - _ Is this a known issue? Is this a bug? or is there some configuration thing I have to do?? Brian Kelly "WellChoice, Inc." made the following annotations on 08/18/2003 03:08:03 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: No output from DOS commands via telnet using xinetd
"The silence is deafening". Apparently there aren't too many folks using telnet with xinetd ( I know, I know, SSH is what everyone's doing ). Anyhow, I do have a fairly important need for this combo, and the problem outlined below is a significant one for me. Before I do anything else - I would *really* like to know at least, if anyone else gets the same behavior. That would at least establish that I'm dealing with a legitimate bug rather than a setup or configuration issue. Just a "me too" - or "works for me" would be MUCH appreciated. Brian Kelly Brian Kelly 08/18/2003 03:05 PM To:[EMAIL PROTECTED] cc: Subject:No output from DOS commands via telnet using xinetd I've noticed that running most DOS commands via telnet using *xinetd* produced no output. Runing DOS commands via telnet using *inetd* works as expected and DOES produce the expected output. For instance, in telnet via inetd, typing: net help produces the following output: - [EMAIL PROTECTED] ~ - net help The syntax of this command is: NET HELP command -or- NET command /HELP Commands available are: NET ACCOUNTS NET HELP NET SHARE NET COMPUTER NET HELPMSG NET START NET CONFIG NET LOCALGROUPNET STATISTICS NET CONFIG SERVERNET NAME NET STOP NET CONFIG WORKSTATION NET PAUSE NET TIME NET CONTINUE NET PRINT NET USE NET FILE NET SEND NET USER NET GROUPNET SESSION NET VIEW NET HELP SERVICES lists the network services you can start. NET HELP SYNTAX explains how to read NET HELP syntax lines. NET HELP command | MORE displays Help one screen at a time. [EMAIL PROTECTED] ~ - --- In telnet via xinetd, their is NO output from the same command: --- [EMAIL PROTECTED] ~ - net help [EMAIL PROTECTED] ~ - --- Also, if you run a DOS shell via telnet through inetd, you can see the output of unix/cygwin commands: [EMAIL PROTECTED] ~ - cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. e:\temp>pwd pwd /cygdrive/e/temp e:\temp>exit exit [EMAIL PROTECTED] ~ Output of same pwd command when run via telnet through xinetd: [EMAIL PROTECTED] ~ - cmd Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. e:\temp>pwd pwd e:\temp>exit exit [EMAIL PROTECTED] ~ - _ Is this a known issue? Is this a bug? or is there some configuration thing I have to do?? Brian Kelly "WellChoice, Inc." made the following annotations on 08/20/2003 08:26:38 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: No output from DOS commands via telnet using xinetd
Thanks Elfyn - you did a great job fixing the *silence* problem ;-) Yea - I guess if I want it, I got to do some work to get it. I'll try running those traces later today if I get some time. In the meantime if anyone else can run a quick test, you'd be "helping the cause" - something to feel *good* about. ;-) Brian Kelly "Elfyn McBratney" <[EMAIL PROTECTED]>@cygwin.com on 08/20/2003 08:50:43 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: No output from DOS commands via telnet using xinetd Elfyn McBratney <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > "The silence is deafening". Apparently there aren't too many folks using > > telnet with > > xinetd ( I know, I know, SSH is what everyone's doing ). Anyhow, I do have > > a fairly important > > need for this combo, and the problem outlined below is a significant one > > for me. Before I > > do anything else - I would *really* like to know at least, if anyone else > > gets the same behavior. > > That would at least establish that I'm dealing with a legitimate bug rather > > than a setup > > or configuration issue. Just a "me too" - or "works for me" would be MUCH > > appreciated. > > You could try attaching to the xinetd (and inetd) process with strace to see > if there's a noticable difference somewhere. Hmmm... What I meant to say is attach *to* the telnetd processes not the *inetd processes. -- Elfyn -- 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/ "WellChoice, Inc." made the following annotations on 08/20/2003 08:55:44 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: init and xinetd woes
> hello all, > I've been messing around with xinetd and init and I can't seem to get them > to play nicely together. > I've checked the archives and have reinstalled xinetd, sysvinit, > initscripts, etc., run the appropriate config files (overwriting existing > /etc/*config files) and I still can't get init to start xinetd. > /var/log/init.log is empty > net start init produces the following output: > INIT: version 2.84 booting > INIT: Entering runlevel: 3 > INIT: no more processes left in this runlevel init is HYPER sensitive to the owner and group settings on the /var directory. To *just* get it working, try this: chown -R SYSTEM:None /var Better security can be had with this depending on the group membership of the SYSTEM user: chown -R SYSTEM:Administrators /var Or - if you've created a custom user, like "root": chown -R root:Administrators /var Make sure that the *user* init is configured to use has write permissions: chmod -R 755 /var If you want the group to have write permissions as well: chmod -R 775 /var Also, consult the archives for previous discussions (like this one) http://sources.redhat.com/ml/cygwin/2003-08/msg00440.html Enjoy, Brian Kelly (Oh - and yes - the error messages *SUCK* - obviously created for the developers use and *not* end-users. A big PET PEEVE of mine - the developer's ultimate revenge against the dreaded demanding and *ungrateful* user. Actually, it's a sin of "omission" - but a sin nevertheless. Of course they'll all cry overworked, underpaid (or not paid as the case certainly is here - unless you work for Red Hat), "don't like it - do it yourself", *&%$ YOU!: http://sources.redhat.com/ml/cygwin/2003-08/msg00454.html etc etc. But alas - it is what it is ... I've always found the notion that "complaints" == "ungrateful" and that I or anyone else should "thankfully" accept whatever is created - even if takes 10 wasted hours from our lives that could have been prevented with ten or fifteen minutes worth of effort by the developer - *without complaint* to be a bunch of HOOEY! Add up your ten hours, my ten hours, and the ten hours of all those before and after and this *sin of omission* becomes quite glaring) "WellChoice, Inc." made the following annotations on 08/21/2003 07:30:48 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 & Domain Users
mkpasswd -d -u Brian Kelly "Doug Jenkinson" <[EMAIL PROTECTED]>@cygwin.com on 08/22/2003 01:48:16 PM Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Cygwin & Domain Users Hi All, I recently got a new laptop, and my account is part of a domain and not a local one. As such, the cygwin config doesn't recognize it. My first thought was to just edit /etc/passwd file, but I can't figure out what my account's SUID is (that big long identifier that Win2k uses). I'm sure once I look at a guide for the formatting of the file, I can get the other factors. Does anyone know how to get that? Easier still, does anyone know how to easily add my account to the file, or to the cygwin setup? As for various needed details, this is a fresh install of cygwin from 8/18/03 on Windows 2000. Thanks in advance. Doug Jenkinson __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/22/2003 02:00:40 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: ftp crash with latest inetutils and cygwin 1.5
cgf seems to think that working himself to death gives him the right to be the *meanest* person on the list! ... hmmm ... GUESS IT DOES ;-) Thanks! Brian Kelly "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 08/31/2003 02:41:43 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: ftp crash with latest inetutils and cygwin 1.5 On Sun, Aug 31, 2003 at 01:45:04AM -0400, Christopher Faylor wrote: >My plan is to allocate the memory for these char ** arrays >contiguously and avoid using the internal structure pointers >directly. If this makes sense to anyone and you want to submit >a patch or check in a fix, feel free. Otherwise, I'll get to this >tomorrow. Actually, don't bother. I think I've got it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 08/31/2003 09:01:11 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
WOOO HOOO!!!! 1.5.3 Fixes This!!! Re: No output from DOScommands via telnet using xinetd
*Kisses and flower petals* ;-) for cgf, Corrina, Igor, Elfyn, and all the rest who helped make this happen!!! Brian Kelly Brian Kelly 08/20/2003 08:56 AM To:[EMAIL PROTECTED] cc: Subject:Re: No output from DOS commands via telnet using xinetd (Document link: Brian Kelly) Thanks Elfyn - you did a great job fixing the *silence* problem ;-) Yea - I guess if I want it, I got to do some work to get it. I'll try running those traces later today if I get some time. In the meantime if anyone else can run a quick test, you'd be "helping the cause" - something to feel *good* about. ;-) Brian Kelly "Elfyn McBratney" <[EMAIL PROTECTED]>@cygwin.com on 08/20/2003 08:50:43 AM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: No output from DOS commands via telnet using xinetd Elfyn McBratney <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > "The silence is deafening". Apparently there aren't too many folks using > > telnet with > > xinetd ( I know, I know, SSH is what everyone's doing ). Anyhow, I do have > > a fairly important > > need for this combo, and the problem outlined below is a significant one > > for me. Before I > > do anything else - I would *really* like to know at least, if anyone else > > gets the same behavior. > > That would at least establish that I'm dealing with a legitimate bug rather > > than a setup > > or configuration issue. Just a "me too" - or "works for me" would be MUCH > > appreciated. > > You could try attaching to the xinetd (and inetd) process with strace to see > if there's a noticable difference somewhere. Hmmm... What I meant to say is attach *to* the telnetd processes not the *inetd processes. -- Elfyn -- 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/ "WellChoice, Inc." made the following annotations on 09/02/2003 11:25:49 AM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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 deadlocks due to broken select() when writing to pipes
Thank you Bob Byrnes for this info and analysis. Perhaps it will result in a solution to a long simmering problem. I use cygwin VERY aggressively. A cron job launches a 20,000 line perl script (not including CPAN modules by other authors) that does complex network automation tasks via multiple chained telnets and ftps. (Eventually to use ssh). Cron launches this script every five minutes and multiple instances share resources managed by semaphores. cgf wasn't even remotely in the mood for endorsing cygwin for this kind of 'abuse' (not his exact words). Nevertheless, for "the most part" it works extraordinarily well. My biggest headache is - occasional DEADLOCKS. About once or twice a day a bash process attempting to start an ftp instance will hang - and freeze everything clear up to the perl parent process that launched it. Perl itself even hangs and stops writing output to log files and the terminal. The deadlock situation will last indefinitely until I do a kill -9 and terminate the last bash shell launched by the perl script. Then, every other process associated with the parent perl script "comes back to life". I am not a c/c++ programmer. My expertise is in Perl - and there it shall remain. I spent a couple hours a few weeks ago trying to incorporate strace into the mix I run, but it turned out to be a really complicated undertaking - so I gave up on it. So I apologize for effectively offering nothing more than a BIG "me too!!". That said . ME TOO!!! Brian Kelly -- 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 deadlocks due to broken select() when writing to pipes
> So, predictably, we will now be seeing everyone who has ever seen a hang > anywhere near cygwin chiming in with a "THIS MUST BE IT!" So "this *probably* is it" would make you feel better? ( No I didn't think so either ). Assuming you're *human* cgf ;-), you're *interest* in hunting down any particular intermittent and well hidden bug would be in pretty close relation to the number of folks experiencing it as a problem - however "nebulously". Squeaky wheel gets the grease - squeaky wheel*s* get a factory recall. It's pretty obvious that the number of "me too's" are sufficient only to *irritate* - not *interest* you - at this point. Nevertheless, a few persistent reminders over a long period can have the same effect as a very large number of complaints in close proximity. There was once a great story in the Reader's Digest I think of some prisoner somewhere who decided that it'd be nice to have a new library in the prison. So he started writing lawmakers and telling them that he wanted a new library for the prison. Every day he mailed a couple of dozen hand written letters. For three of four years they were ignored. Then eventually he started getting VERY nasty responses telling him to bug off. Some even called the warden to get him to stop, but civil libertarians soon took interest in this and threatened to sue on his behalf if his mail was censured. Finally everyone was eventually worn down and around year ten, the legislature voted to fund the construction of his library - allocating close to TWO MILLION DOLLARS for the effort. As for your *mean* response serving as a deterrent - your ongoing rant about not wanting to hear from non-contributors is just that - ongoing ... Brian Kelly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Thursday, October 30, 2003 11:36 PM To: [EMAIL PROTECTED] Subject: Re: cygwin deadlocks due to broken select() when writing to pipes On Thu, Oct 30, 2003 at 11:14:36PM -0500, Brian Kelly wrote: >Thank you Bob Byrnes for this info and analysis. Perhaps it will >result in a solution to a long simmering problem. I use cygwin VERY >aggressively. A cron job launches a 20,000 line perl script (not >including CPAN modules by other authors) that does complex network >automation tasks via multiple chained telnets and ftps. (Eventually to >use ssh). Cron launches this script every five minutes and multiple >instances share resources managed by semaphores. cgf wasn't even >remotely in the mood for endorsing cygwin for this kind of 'abuse' (not >his exact words). Nevertheless, for "the most part" it works >extraordinarily well. So, predictably, we will now be seeing everyone who has ever seen a hang anywhere near cygwin chiming in with a "THIS MUST BE IT!" I am always interested in fixing bugs in cygwin but bugs like of "I run it for a real long time and something bad happens. I'm not a programmer and have no idea how to provide any useful feedback" are onex I steer clear of. Perhaps this mean response will serve as a deterrent for anyone (except possibly one of my "groupies" who occasional pop up to comment on my character flaws and then disappear) from responding unless there is real useful data to provide? >I am not a c/c++ programmer. My expertise is in Perl - and there it >shall remain. If that is the case, then why are you presuming that the described problem has anything to do with you? You have admitted that you couldn't possibly know if the programs that you are using are performing a select on a pipe since you don't know c or c++. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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 deadlocks due to lack of money
> You can donate money. Fair enough. How? I saw nothing on the cygwin website explaining how this could be done. I'd want donations used explicitly for cygwin. BK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Friday, October 31, 2003 1:33 AM To: [EMAIL PROTECTED] Subject: Re: cygwin deadlocks due to broken select() when writing to pipes On Fri, Oct 31, 2003 at 12:59:17AM -0500, Brian Kelly wrote: >Nevertheless, a few persistent reminders over a long period can have >the same effect as a very large number of complaints in close >proximity. > >There was once a great story in the Reader's Digest I think of some >prisoner somewhere who decided that it'd be nice to have a new library >in the prison. So he started writing lawmakers and telling them that >he wanted a new library for the prison. Every day he mailed a couple >of dozen hand written letters. For three of four years they were >ignored. Then eventually he started getting VERY nasty responses >telling him to bug off. Some even called the warden to get him to >stop, but civil libertarians soon took interest in this and threatened >to sue on his behalf if his mail was censured. Finally everyone was >eventually worn down and around year ten, the legislature voted to fund >the construction of his library - allocating close to TWO MILLION >DOLLARS for the effort. You can buy books. You can donate money. You can't cause a problem to be solved just by incessantly complaining about it. If this technique was uniformly useful then we'd have peace in the Middle East and my son would have a telephone in his room. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- 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 deadlocks due to broken select() when writing to pipes
> and my son would have a telephone in his room. Do you have a cordless phone? - Then your son has *already* had a phone in his room! > If this technique was uniformly useful then we'd have peace in the Middle > East Persistence has to be uniform, consistent, morally obvious, concretely defined and *limited* in it's objectives. *Peace* in the Middle East demanded by those engaging in non-peaceful tactics violates all of the above. Some of "my" tactics violate some of the above tenets. I admittedly am not consistent nor sufficiently limited in my objectives ... I suppose this makes me simply an irritant ( and off-topic ) I'll stop now. Thanks for all you HAVE done ;-) -- 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/
Will next cygwin1.dll release have the select() fix?
Will the next cygwin1.dll release have cgf's select() fix? And when is the next version planned for release? (I know a snap-shot is available). Brian Kelly "WellChoice, Inc." made the following annotations on 11/14/2003 12:52:23 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Will next cygwin1.dll release have the select() fix?
> I'm wondering what you think the term "snapshot" means. cvs - as opposed to setup.exe So I take it I'm wrong and can get the select() fix via default setup.exe? > Standard flip answer: Definitely by December 2004. Is there such a thing as a standard "non-flip" answer? BK "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 11/14/2003 02:13:45 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Will next cygwin1.dll release have the select() fix? On Fri, Nov 14, 2003 at 12:52:03PM -0500, [EMAIL PROTECTED] wrote: >Will the next cygwin1.dll release have cgf's select() fix? I'm wondering what you think the term "snapshot" means. >And when is the next version planned for release? Standard flip answer: Definitely by December 2004. -- Please use the resources at cygwin.com rather than sending personal email. Special for spam email harvesters: send email to [EMAIL PROTECTED] and be permanently blocked from mailing lists at sources.redhat.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 11/14/2003 02:48:51 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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: Will next cygwin1.dll release have the select() fix?
> Gold star for Brian! Please - even thankless ungrateful lamprey-eel me knows you're not really serious about giving your tag team coat-tailer a *real* gold star for this! (I'll believe it when I see it on the website). -bk "Christopher Faylor" <[EMAIL PROTECTED]>@cygwin.com on 11/14/2003 03:13:28 PM Please respond to [EMAIL PROTECTED] Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Brian Kelly/WTC1/Empire) Subject:Re: Will next cygwin1.dll release have the select() fix? On Fri, Nov 14, 2003 at 02:10:53PM -0600, Brian Ford wrote: >On Fri, 14 Nov 2003 [EMAIL PROTECTED] wrote: >>>I'm wondering what you think the term "snapshot" means. >> >>cvs - as opposed to setup.exe > >What do you think the cvs repository is for? > >>So I take it I'm wrong and can get the select() fix via default >>setup.exe? >> >Not now, but the next release will be based off cvs. Doh! > >That is what snapshots are for, to test for a yet to be determined >future release. > >>>Standard flip answer: Definitely by December 2004. >> >>Is there such a thing as a standard "non-flip" answer? >> >Cygwin is a voluteer effort. Releases do not happen on a schedule. >Volunteer yourself, or take what you get. Gold star for Brian! cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ "WellChoice, Inc." made the following annotations on 11/14/2003 03:40:49 PM -- Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement -- 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/
